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 <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
