This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] vmx & efer

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 07.05.07 10:43 >>>
>On 7/5/07 09:35, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>> The bit LMA and LME are automaticaly are loaded by the hardware. Please
>>> look at the spec (Volume 3B).
>> Hmm, that cannot be fully true. The description for bit 9 of the VM-Entry
>> control field says: "Its value is loaded into IA32_EFER.LMA and IA32_EFER.LME
>> as part of VM entry." However, even if the bit is clear the processor must
>> remain in 4-level paging mode, and unless I'm missing something there's no
>> separation between a bit controlling long mode in terms of the effect the
>> L-bit of a code descriptor has (and e.g. requiring 64-bit gates in descriptor
>> tables) and a bit controlling the paging mode. So in reality there must be
>> two bits (and hence neither of them can be considered EFER.LME or EFER.LMA).
>You seem to be assuming that if the hypervisor executes with 4-level
>pagetables then so must all VMX guests. This isn't true. A VMX VCPU running
>in 32-bit mode (PAE or not) will execute with 3-level pagetables when
>running on x86/64 Xen.

Oh, okay, I didn't realize that. That makes things look consistent again, as 
as you are saying that in this mode the physical CR3 continues to be a 64-bit


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>