On 09/26/2010 03:06 PM, Nadav Har'El wrote:
On Sun, Sep 26, 2010, Avi Kivity wrote about "Re: [PATCH 16/24] Implement VMLAUNCH and VMRESUME":
> I don't see how vcpu->arch.cr0 can cache cr0_read_shadow.
But this is precisely what the (unpatched) vmx_set_cr0 code does:
If you look at it, it takes a parameter "cr0" and builds an additional
variable "hw_cr0".
"cr0" gets written into CR0_READ_SHADOW, while "hw_cr0" gets written into
GUEST_CR0.
vcpu->arch.cr0 gets a copy of "cr0", not of "hw_cr0", i.e., it is a cache of
CR0_READ_SHADOW, not of GUEST_CR0.
Or am I missing something?
In vmx, cr0 is split into two registers, CR0_READ_SHADOW and GUEST_CR0.
nvmx needs to split vCR0_READ_SHADOW and vGUEST_CR0 into three.
vCR0_READ_SHADOW can be assigned directly to CR0_READ_SHADOW.
vGUEST_CR0 can be copied to vcpu->arch.cr0 so the mmu acts according to
the mode L1 thinks it places L2 into (but not what L2 thinks it is in).
vGUEST_CR0, appropriately munged (by ORing it with KVM_VM_CR0_ALWAYS_ON
and doing the TS games) is assigned to GUEST_CR0.
We need to audit all code that touches vcpu->arch.cr0; but I think this
split is the easiest one. The only code that needs to change is the
cr0/lmsw emulation code (writes need to consider vCR0_GUEST_HOST_MASK).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
