Re: [PATCH 16/24] Implement VMLAUNCH and VMRESUME

[Avi Kivity <avi@redhat.com>]

  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