Large Page Tables gives page fault

[0bwan]

I get a VBOX-only page fault enabling large page tables. Code snippet below.

Same code/same and host using VMWARE, BOCHS, and QEMU works just fine, although I did have to enable large page support in BOCHS and QEMU.

VBOX is the odd one out, which is a shame as it's my favorite virtualization tool.

The CPUID 0x80000001 does not give me EDX BIT 26 (pdpe1gb). Enabling this via the cpuid-set command is ignored.

Any idea of the correct (exact) setting to enable pdpe1gb support?

Many thanks!
DP

Code: Select all

	MOV EAX, 0x80000001
	CPUID
	AND EDX, pdpe1gb      ;macro 0x1 << 26

	JNZ long_mode_1g_page_tables_available
	
	WRITE_TERMINAL_32 `Machine does not support 1 GiB Page Tables. Terminating.\n`
	WAIT_FOREVER
	
long_mode_1g_page_tables_available:

	MOV DWORD EAX, LONGMODE_PDPTE_ADDR

	OR DWORD EAX, 0b011  
	MOV DWORD [LONGMODE_PML4E_ADDR], EAX
	MOV DWORD [LONGMODE_PML4E_ADDR + 4], 0

	MOV EAX, 0			 ;first page address
	MOV EBX, 0b10000011	 ;flags: rw + final entry (no PDE or lower)
	MOV ECX, 0x200       	;number of entries
	MOV EDI, LONGMODE_PDPTE_ADDR; first destination address 
	.pdpte_loop:
		MOV [EDI], EBX			;store flags
		MOV [EDI + 4], EAX		;store address
		ADD EDI, 8				;next entry
		ADD EAX, 0b100000000000000000000; next page address
	LOOP .pdpte_loop

[klaus]

Why spend time on implementing something which at best gives a handful of people on this planet something crazy to play with? There's no OS out there which would insist on using 1GB pages.

[0bwan]

Thanks for the response but it avoids an answer, does not give a way forward and demotivates.

I have 6 virtual environments. Only one appears not to support 1G entries - Virtualbox.

1g tables allows more efficient simulation of flat physical ram without the memory overhead of smaller PTEs. Critical in an ultra high efficiency custom guest OS. Not to mention the additional initialization steps.

Does anyone know if VBox can be configured to enable them? The flag exists in the source code, so I suspect a TODO or bug somewhere. Writing an OS and TCP stack in pure assembly is time consuming, and having a definitive straight answer would allow us to keep our focus.

Thanks in advance.

[andyp73]

Thanks for the response but it avoids an answer, does not give a way forward and demotivates.

On the contrary, it gives you an answer, just not the one you wanted. VirtualBox at present doesn't support it and they aren't going to spend time on implementing it until a paying customer has a need for it. It may be that they already have one but as the devs don't give us any of that kind of information then there is no way of knowing.

I have 6 virtual environments. Only one appears not to support 1G entries - Virtualbox.

In which case, VirtualBox doesn't meet your needs and so you will have to look at one of the others. It is no different to buying a car - the latest Italian sports car may look good but if you need to transport livestock they aren't the vehicle you need!

Writing an OS and TCP stack in pure assembly is time consuming

...then don't do it! There is almost certainly an OS out there already that does what you need and has some development pedigree!

-Andy.

[DrScriptt]

There is almost certainly an OS out there already that does what you need and has some development pedigree!

Linux, QNX, GNU/Hurd, etc. had no pedigree when they started. Would you have made your comment to Linus T., or Gordon B., or Dan D., or Richard S. when they started? Would you still make your comment to them today?

Perhaps 0bwan is working on something that will be a household name in 20 years. Far be it from me to dissuade him / her.

I hoist my tankard to 0bwan and wish him / her good luck.