Re: [PATCH 3/4] KVM: nVMX: Check all exceptions for intercept during delivery to L2

[Gleb Natapov <gleb@redhat.com>]

On Wed, Sep 25, 2013 at 12:38:20PM +0200, Paolo Bonzini wrote:
> Il 25/09/2013 11:51, Gleb Natapov ha scritto:
> > All exceptions should be checked for intercept during delivery to L2,
> > but we check only #PF currently. Drop nested_run_pending while we are
> > at it since exception cannot be injected during vmentry anyway.
> > 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  arch/x86/kvm/vmx.c | 8 +++-----
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index 663bc5e..5bfa09d 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -1902,12 +1902,11 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
> >   * a #PF exception (this is the only case in which KVM injects a #PF when L2
> >   * is running).
> >   */
> > -static int nested_pf_handled(struct kvm_vcpu *vcpu)
> > +static int nested_ex_handled(struct kvm_vcpu *vcpu, unsigned nr)
> >  {
> >  	struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
> >  
> > -	/* TODO: also check PFEC_MATCH/MASK, not just EB.PF. */
> > -	if (!(vmcs12->exception_bitmap & (1u << PF_VECTOR)))
> > +	if (!(vmcs12->exception_bitmap & (1u << nr)))
> >  		return 0;
> >  
> >  	nested_vmx_vmexit(vcpu);
> > @@ -1921,8 +1920,7 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
> >  	struct vcpu_vmx *vmx = to_vmx(vcpu);
> >  	u32 intr_info = nr | INTR_INFO_VALID_MASK;
> >  
> > -	if (!reinject && nr == PF_VECTOR && is_guest_mode(vcpu) &&
> > -	    !vmx->nested.nested_run_pending && nested_pf_handled(vcpu))
> > +	if (!reinject && is_guest_mode(vcpu) && nested_ex_handled(vcpu, nr))
> 
> The code is now pretty similar to what svm.c does.  Do we want to move
> the is_guest_mode(vcpu) check into nested_ex_handled, too?  (Or vice
> versa, take it out in svm.c).  Perhaps you could also name the function
> nested_vmx_check_exception.
> 
I want to try to move the logic into common code eventually. I do not
mind renaming for now, but it will have to wait for the next week :)


--
			Gleb.