Intel VT physical addresses and PAE

Intel VT physical addresses and PAE

Intel VT contains instructions which takes a memory operand containing a 64-bit physical address. On Intel 64 capable processors, the docs states that bits 63:MAXPHYSADDR must be zero, which is correct. But on 32-bit only processors, the docs states that bits 63:32 must be zero, which would be correct, except that all of the 32-bit only processors that have VT extensions also support PAE, so it should really be bits 63:36 must be zero.

publicaciones de 7 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

PAE reserved bits for 32-bit (IA32) are zero forbits 63:maxphyaddr.

Check out the Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide at

http://www.intel.com/products/processor/manuals/

In particular, seeSection 3.8, Figure 3-20. Above the figure, the 2nd bullet from the top of the page gives the maxphyaddr value as 36.

David Ott

Another domain experiment recently sent methese comments:

"When an IA32e-capable CPU works in 32-bit mode with PAE on, the 64:32 of the 64-bit controls must be zero?"
Answer: no

"A CPU can support 32-bit with PAE on, and doesn't support IA32e; when it works on 32-bit PAE mode, the 64:32 of the 64-bit controls must be zero??"
Answer: yes

"Does this imply 32-bit PAE VMM must allocate the machine physical page for the 64-bit controls only below 4G?"
Answer: This is true unless the VMM checks first to see if the CPU supports IA-32e mode; if the CPU does, the VMM can locate the pages above 4GB. (By "the machine physical page for the 64-bit controls," I assume you mean physical pages referenced by the relevant 64-bit addresses that are controls in the VMCS.)

David Ott

HI,

Hoping someone can help. I am working on getting an OS booted in VMM

mode on an intel processor. I am using OWC 17 as the compiler(does not support Intel vmx instruction set). So far I have paging enabled and working. (32 bit mode with segmentation

enabled). I checked the cpuid for the processor I am using and it does

support VMX. I allocate a region in memory equal to size shown in

IA32_VMX_BASIC_MSR (bits44:32) = 800 so I set it up as 2048 = 2k

region size and set the VMCS revision Identifier as shown in bits 31:0

of this msr = 13 (on my test processor). It is 4k aligned region. My

vmxon address is 66c000 (looks ok). Control Registers:

CR0 = 8001003b

CR4 = 2200

IA32_FEATURE_CONTROL MSR = 0xd

IA32_EFER.LMA = 0x0

EFLAGS = 246

A20 = 0x0

Then when I call vmxon I get interrupt 13 a GP - seems to not like my

memory reference to the vmxon region?

Watcom does not have support for the Intel VMX instruction set so had

to add lib with opcode for vmxon

unsigned long long vmxon_region;

void __near vmxon(void);

#pragma aux vmxon = \

"nop" \

"nop" \

"push ebx" \

"mov ebx, offset vmxon_region" \

"nop" \

"nop" \

0xF3 0x0F 0xC7 0x33 \

"nop" \

"nop" \

"pop ebx" \

"nop" \

"nop";

I assign the 32 bit addres to vmxon_region (a 64 bit long long) in

another function and then call vmxon. I am not real clear about how

vmxon works does it take indirect or direct address? Tried both and

haven't gotten anything but GP

What VMXON takes is a reference to a memory location that always contains a *64-bit physical* address (regardless of which mode you are running in) which in turn points to the VMXON region.

Ok, opcode seems to be correct and the references to memory seems to be correct. Made sure the vmxon region was within the data segment. Still not sure why I am getting a GP. Tried using F3 instead of 33 and still get GP?

Check to ensure CR0.PG, CR0.NE, CR0.PE, and CR4.VMXE is enabled.
Update: Ignore this, it is enabled.

Inicie sesión para dejar un comentario.