Re: [PATCH v3 1/6] KVM: nVMX: Replace kvm_set_cr0 with vmx_set_cr0 in load_vmcs12_host_state

[Gleb Natapov <gleb@redhat.com>]

On Tue, Sep 10, 2013 at 09:14:14PM +0800, Arthur Chunqi Li wrote:
> On Mon, Sep 2, 2013 at 4:21 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Aug 08, 2013 at 04:26:28PM +0200, Jan Kiszka wrote:
> >> Likely a typo, but a fatal one as kvm_set_cr0 performs checks on the
> > Not a typo :) That what Avi asked for do during initial nested VMX
> > review: http://markmail.org/message/hhidqyhbo2mrgxxc
> >
> > But there is at least one transition check that kvm_set_cr0() does that
> > should not be done during vmexit emulation, namely CS.L bit check, so I
> > tend to agree that kvm_set_cr0() is not appropriate here, at lest not as
> > it is. But can we skip other checks kvm_set_cr0() does? For instance
> > what prevents us from loading CR0.PG = 1 EFER.LME = 1 and CR4.PAE = 0
> > during nested vmexit?  What _should_ prevent it is vmentry check from
> > 26.2.4
> >
> > If the "host address-space size" VM-exit control is 1, the following
> > must hold:
> >  - Bit 5 of the CR4 field (corresponding to CR4.PAE) is 1.
> Hi Jan and Gleb,
> Our nested VMX testing framework may not support such testing modes.
> Here we need to catch the failed result (ZF flag) close to vmresume,
> but vmresume/vmlaunch is well encapsulated in our framework. If we
> simply write a vmresume inline function, the VMX will act unexpectedly
> when it doesn't cause "vmresume fail".
> 
> Do you have any ideas about this?
> 
I am not sure what you mean. The framework does capture failed vmentry
flags, but it handles the failure internally in vmx_run(). If you want
framework to be able to provide vmentry failure handler do what Paolo
suggests.

--
			Gleb.