RE: large memory support for x86

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Fri Oct 13 2000 - 14:19:40 EST


On Fri, 13 Oct 2000, Chris Swiedler wrote:
>
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated using the
> "current" segment descriptor, right? It seems to me that a process could set
> a new segment selector, in which case a dereference would operate on a whole
> new segment. Is there a reason why processes are limited to a single
> segment?
>
> chris

You can (although not in user-mode). The problem is; "What RAM do you
reference?". You have 32-bits worth of addressing available in some
machine that has 32-bits worth of addressible RAM.

What can be done is to set one page to be 'not present'. Then, when
you page-fault, the page-fault handler can set some bit(s) in a
hardware page-register to map in another bank of RAM that isn't in
use yet. In principle, this would allow access to (2^16/8 -1) * (2^32 -1)
unique areas of RAM (segment descriptors are 16 bits, but they are
numbered in increments of 8.

So, you now want to copy from a segment addressed by DS, back to your
original DS, you have to rewrite the 'C' runtime library to use
'full pointers', i.e., DS:ESI, ES:EDI, etc., with ES and ES being
different. You have to dereference the full pointer on avery access!

Caching has to be turned off when RAM values that may be in the cache
reference RAM that is not back-switch in. You would have a slow mess.

However, in principle it could work.

Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST