Hi,
hegde1997 wrote:Can someone pls tell me how the 4kb pages or 2mb pages can be made up to so many gbs?
The width of physical addresses is increased up to whatever CPUID says the physical address width is (up to 52-bits), or 36-bit if CPUID doesn't support the physical address width feature. If physical addresses are 36-bit then there's 64 GiB of physical address space; and if there's 52-bit physical addresses then there's 4194304 GiB of physical address space. The size of page table entries (and page directory entries, etc) had to be increased to 8 bytes to accommodate the larger/wider physical addresses.
Virtual (linear) addresses are still only 4 GiB.
8 bytes per page table entry means that only 512 page table entries fit in 4 KiB. The same happens with page directories (only 512 entries in page directories). With less entries in page tables and page directories, page tables and page directories alone aren't enough to cover the full 4 GiB virtual address space (one page table covers an area of 512 * 4096 = 2 MiB and one page directory covers an area of 512 * 2 MiB = 1 GiB). To make it cover the entire 4 GiB virtual address space they had to use 4 page directories, and added a "page directory pointer table" to contain the physical addresses of each of the 4 page directories.
To convert a (32-bit) virtual address into an (up to) 52-bit physical address, the CPU:
- uses CR3 to determine the physical address of the page directory pointer table
- uses the highest 2 bits (bits 30 to 31) of the virtual address to determine which page directory pointer table entry
- uses the page directory pointer table entry to find the physical address of the page directory
- uses bits 21 to 29 of the virtual address to determine which page directory entry
- uses the page directory entry to find the physical address of the page table
- uses bits 12 to 20 of the virtual address to determine which page table entry
- uses the page table entry to find the physical address of the page
- uses bits 0 to 11 of the virtual address to determine the offset within the page
- adds the offset within the page to the physical address of the page to find the final physical address
Note 1: Because CR3 is still only 32-bit, the page directory pointer table's physical address must be below 0xFFFFFFFF even though everything else (page directories, page tables and pages) may have higher physical addresses. This means that your physical memory manager needs to be able to allocate pages that are guaranteed to be below 0xFFFFFFFF.
Note 2: The width of physical addresses mostly only effects code that assigns areas to memory mapped PCI devices (e.g. if/when you're configuring a PCI device's BARs). The memory map provided by the firmware won't include RAM that the CPU can't access (because the computer/hardware can't support that much RAM to begin with), so the width of physical addresses doesn't effect physical memory management.
Note 3: Some CPUs (e.g. some Intel Atom CPUs) support PAE but only support 32-bit physical addresses. This means that you can't assume the CPU supports "at least 36-bit" physical addresses. In this case, the only benefit of using PAE (and consuming more RAM for page tables, page directories, etc) is that PAE supports "no execute" protection while plain paging doesn't.
Note 4: Some Pentium 4 CPUs have a bug where CPUID tells you that 40-bit physical addresses are supported even though the CPU only supports 36-bit physical addresses.
Cheers,
Brendan
