Why does the vmx code maintain hvm_vmx.cpu_cr0?
I see code in vmx.c that keeps v->arch.hvm_vmx.cpu_cr0 up to date, and each
change is faithfully written to the vmcs using __vmwrite(GUEST_CR0, ...)
I also see that the CR0_GUEST_HOST_MASK is always all ones (~0UL), set in
construct_vmcs() and never modified.
However according to section 2.6.6 of the VT specification the value in
GUEST_CR0 is irrelevant if CR0_GUEST_HOST_MASK is all ones.
When the guest reads CR0, the mask will force it to see only the bits in
CR0_READ_SHADOW.
When the guest modifies CR0, the mask will force a vmexit.
So the vmcs value in GUEST_CR0 is never visible to the guest and never
really needed by the host.
It looks to me like the code that maintains hvm_vmx.cpu_cr0 and GUEST_CR0 is
superfluous.
The same argument applies to hvm_vmx.cup_cr4 and GUEST_CR4.
Am I missing something?
--
--------------------------------------------------------------------
Robert S. Phillips Virtual Iron Software
rphillips@virtualiron.com Tower 1, Floor 2
978-849-1220 900 Chelmsford Street
Lowell, MA 01851
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Robert Phillips wrote:> Why does the vmx code maintain hvm_vmx.cpu_cr0?The implementation of hvm_funcs.get_guest_ctrl_reg() would be awkward since you would have make sure to load the vmcs for the VCPU you''re interested in on the current PCPU before attempting to vmread(GUEST_CR0). Regards, Anthony Liguori> I see code in vmx.c that keeps v->arch.hvm_vmx.cpu_cr0 up to date, and > each change is faithfully written to the vmcs using __vmwrite(GUEST_CR0, > ...) > I also see that the CR0_GUEST_HOST_MASK is always all ones (~0UL), set > in construct_vmcs() and never modified. > > However according to section 2.6.6 of the VT specification the value in > GUEST_CR0 is irrelevant if CR0_GUEST_HOST_MASK is all ones. > When the guest reads CR0, the mask will force it to see only the bits in > CR0_READ_SHADOW. > When the guest modifies CR0, the mask will force a vmexit. > > So the vmcs value in GUEST_CR0 is never visible to the guest and never > really needed by the host. > > It looks to me like the code that maintains hvm_vmx.cpu_cr0 and > GUEST_CR0 is superfluous. > > The same argument applies to hvm_vmx.cup_cr4 and GUEST_CR4. > > Am I missing something? > > -- > -------------------------------------------------------------------- > Robert S. Phillips Virtual Iron Software > rphillips@virtualiron.com > <mailto:rphillips@virtualiron.com> Tower 1, Floor 2 > 978-849-1220 900 Chelmsford Street > Lowell, MA 01851 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 1/2/07 21:49, "Robert Phillips" <rsp.vi.xen@gmail.com> wrote:> The same argument applies to hvm_vmx.cup_cr4 and GUEST_CR4. > > Am I missing something?Yes. GUEST_CR0 and GUEST_CR4 are the actual control-register values loaded into the processor when running in VMX context. This can be different from either the value the guest thinks it¹s running with, and also different from the value loaded into the processor when running in root context (i.e., in Xen). They are cached in software structures because it can save a vmread in some situations, which is worth around 50 cycles even on Core 2. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel