[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: vmcs GUEST_CR0 unused?



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@xxxxxxxxxxxxxxx <mailto:rphillips@xxxxxxxxxxxxxxx> Tower 1, Floor 2
978-849-1220                                 900 Chelmsford Street
                                                    Lowell, MA 01851


------------------------------------------------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.