unclear doubts about pae paging

[hegde1997]

Hello everyone,

I was looking at pae paging in wiki. i did lot of googling and read 3 times the explanation given in Wikipedia. I also sat with calculator and couldnt never understand how one could support 64gb or more with pae paging. they had told that windows 2012 server allows for 192 gb ram. can someone pls tell me how the 4kb pages or 2mb pages can be made up to so many gbs?

Firstly, i am not clear about the things in pae paging. with this, i am also losing understanding of how legacy paging is

so actually what i have understood about pae paging is:
*4byte entries became 8byte wide
* as the entries' width got doubled, the number of entries each page dir, each page table can hold is 512 (before it was 1024)
*there is page dir ptr table and each entry in it points to a page dir.

[Brendan]

Hi,

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

[hegde1997]

So during execution, at any point of time only 4gb of total memory available (say we have system with 16 gb ram) or at any point of time only 4gb of memory can be paged in. am i right?

[Brendan]

Hi,

So during execution, at any point of time only 4gb of total memory available (say we have system with 16 gb ram) or at any point of time only 4gb of memory can be paged in. am i right?

Yes.


Cheers

Brendan

[hegde1997]

thanks.

[rdos]

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.

So how do you detect this bug, and is it only with PAE paging that the CPU only supports 32-bit physical addresses? Logically, the CPU should support the same physical address space with PAE paging as in long mode, but what you are saying is that this doesn't need to be the case?

[Brendan]

Hi,

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.

So how do you detect this bug, and is it only with PAE paging that the CPU only supports 32-bit physical addresses? Logically, the CPU should support the same physical address space with PAE paging as in long mode, but what you are saying is that this doesn't need to be the case?

Physical address size is the same for PAE and long mode. This also means that 64-bit CPUs do exist that only support 32-bit physical addresses.

Note: Intel's Atom CPUs are the only CPUs that I know of that support PAE and are limited to 32-bit physical addresses; and I'm not too sure if this applies to all Atoms or just some models - the CPU I tested is an Atom 330 ("Diamondville"), and I haven't tested later models (Pineview/Cedarview).


Cheers,

Brendan

[rdos]

Hi,

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.

So how do you detect this bug, and is it only with PAE paging that the CPU only supports 32-bit physical addresses? Logically, the CPU should support the same physical address space with PAE paging as in long mode, but what you are saying is that this doesn't need to be the case?

Physical address size is the same for PAE and long mode. This also means that 64-bit CPUs do exist that only support 32-bit physical addresses.

Note: Intel's Atom CPUs are the only CPUs that I know of that support PAE and are limited to 32-bit physical addresses; and I'm not too sure if this applies to all Atoms or just some models - the CPU I tested is an Atom 330 ("Diamondville"), and I haven't tested later models (Pineview/Cedarview).


Cheers,

Brendan

Which should mean that if the memory map from BIOS/GRUB returns physical addresses above 4G, it should be possible to use them both with PAE paging and in long mode (provided the CPU supports PAE and long mode) without extra precautions?

There is also an issue on how much physical RAM a motherboard can support, and few older motherboards support more than 4G. In fact, I don't have a machine with more than 4G RAM installed, but I have at least one where it is possible to add more. I don't think my dual core Intel Atom mini-PC supports more than 4G, and it comes with only 1G preinstalled. It's kind of hard to test the limits when the motherboard lack support for more RAM.

[Brendan]

Hi,

Which should mean that if the memory map from BIOS/GRUB returns physical addresses above 4G, it should be possible to use them both with PAE paging and in long mode (provided the CPU supports PAE and long mode) without extra precautions?

Yes. There's no point designing a motherboard that accepts more RAM than the CPU it's intended for can support. For example, most of the motherboards designed for Atom only support 2 GiB of RAM.


Cheers,

Brendan

[hegde1997]

after loading pdpt address to cr4 when enabling the paging, machine reset/triple fault occurs. any guess why?

Code: Select all

typedef uint32 virt_addr;
typedef uint64 phys_addr;

Code: Select all

#ifdef _PAE_paging_enable

phys_addr pdpt[4] __attribute__((aligned(0x20)));;
phys_addr page_dir[4][512] __attribute__((aligned(0x1000)));
phys_addr page_tab [4][512][512] __attribute__((aligned(0x1000)));
#endif

void mem_paging_init()
{
	#ifdef _PAE_paging_enable
	
		uint8 d,flags=3; uint16 i;
		phys_addr addr=0;
		for(d=0;d<4;d++)
		{
			for(i=0;i<512;i++)//map 1 directory
			{
				mem_fill_pageT(&page_tab[d][i][0],&addr,flags);//map 1 entry
				page_dir[d][i]=((uint64)(page_tab[d][i][0]))|0b11;
			}
		}_printf("\n\t Loading the pdpte to cr3");
		pdpt[0]=((uint64)(_ptr_conv&page_dir[0]))| 1;  //present
		pdpt[1]=((uint64)(_ptr_conv&page_dir[1]))| 0;  //present
		pdpt[2]=((uint64)(_ptr_conv&page_dir[2]))| 0;  //present
		pdpt[3]=((uint64)(_ptr_conv&page_dir[3]))| 0;  //present
		asm volatile ("movl %cr4, %eax; bts $5, %eax; movl %eax, %cr4"); // set bit5 in CR4 to enable PAE
		asm volatile ("movl %%eax, %%cr3" :: "a" (&pdpt)); // load pdpt
		asm volatile ("movl %cr0, %eax; orl $0x80000000, %eax; movl %eax, %cr0;");
		
	#endif

}
void mem_fill_pageT(phys_addr *pagetable,phys_addr *addr,uint16 flags)//maps 1 page table or 1 entry in pagedir
{
	uint16 i;
	for(i=0;i<512;i++)
	{
		if((*addr/4096)>mem_size/4096)
		  flags=(flags>>1)<<1;
		*(pagetable+i)=(*addr|flags);
		*addr+=_page_size;
	}
}

[bluemoon]

Code: Select all

   page_dir[d][i]=((uint64)(page_tab[d][i][0]))|0b11;

This set the page_dir entry to the value of the page_tab's first entry, instead of the address of the table itself.

PS. No, &page_tab[d][0] won't work either, you need the physical address, check the tutorials or ask again if you're not sure.