Messages in this thread |  | | Date | Fri, 13 Oct 2000 15:34:32 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: large memory support for x86 |
| |
On Fri, 13 Oct 2000, Timur Tabi wrote:
> I understand that a normal virtual address (i.e. a pointer) can only address a > single 32-bit (4GB) memory block. My point was that by also using more than > one 16-bit selector, you can have multiple 4GB areas. So for instance, > 1000:00000000 can point to one physical address, and 1001:00000000 can point a > different physical address.
_All_ of them are piped through the 4Gb address space. I.e. every segment is mapped to a part of the same (for all segments) 4Gb. That address space is, in turn, mapped to 64Gb of physical memory. At any moment you can't get more than 2^32 different elements of physical memory accessible, even though you have 48 bits of address in the beginning and 36 bits in the end.
Think of it that way: we have two functions:
u32 map_segment(u48); u36 map_paging(u32);
and processor does map_paging(map_segment(address)) when it calculates the physical addresses. Even though both the range and domain are larger than 2^32, the number of different values is less or equal to it.
> Yes, this means that you need to use multiple selectors in order to access more > than 4GB of virtual space. > > According to section 3.8 of Intel's P3 manual, Volume 3, enabling the PAE > increases the size of the page table entries to 64 bits. There are other > changes, such as extended the 20-bit page directory base address to 27 bits. > All this means that a virtual address (selector:offset) can point to a physical > address larger than 32 bits.
Virtual address gives linear address. _Then_ it is translated into physical address. Page tables describe the latter mapping. Descriptor tables - the former. Size of linear address is the bottleneck here and no changes past that bottleneck can expand the number of possible values.
- 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/
|  |