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

[Xen-devel] vmcs GUEST_CR0 unused?


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Robert Phillips" <rsp.vi.xen@xxxxxxxxx>
  • Date: Thu, 1 Feb 2007 16:49:55 -0500
  • Delivery-date: Thu, 01 Feb 2007 13:49:26 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gEi5pgkSG0ry4+u0bn189aanQWr2HqC7zWqbLSJNK57FLv48SWlOXS7dINuRCsURvEpMxtS0M4EAniZ6KMZf4WpCorBc5L5oRovk0wIvxmMKfPH5mz2d4vNO0a+1S/JWNTz032vIXk7zl3Zo0oR/6LPDkMJR4dXLC3B09HdBH9E=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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@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

 


Rackspace

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