On Wed, Oct 07, 2015 at 11:48:36AM -0400, Bandan Das wrote:
> Ok, understood now. The warn_on would trigger in L1 only if it has
> decided to disable nrips for some reason as was the case here. So,
> my reasoning behind putting the warning was incorrect.
Okay, so I think the warning can be removed.
> > +
> > + if (guest_cpuid_has_nrips(vcpu))
> > + nested_vmcb->control.next_rip = vmcb->control.next_rip;
Note that there is a bug here, instead of vcpu it must be &svm->vcpu.
Somehow I missed to at least compile-test this.
Dirk is currently testing whether this (fixed) patch solves the problem
in his setup.
> >
> > /*
> > * If we emulate a VMRUN/#VMEXIT in the same host #vmexit cycle we have
> > @@ -2714,6 +2716,9 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
> > svm->vmcb->control.event_inj = nested_vmcb->control.event_inj;
> > svm->vmcb->control.event_inj_err = nested_vmcb->control.event_inj_err;
> >
> > + /* Clear next_rip, as real hardware would do */
> > + nested_vmcb->control.next_rip = 0;
> > +
>
> Why do we need this ? And are you sure this is what real hardware does ?
> I couldn't find anything in the spec.
Yeah, probably right. Since we only write guests next_rip when the guest
supports it via cpuid, there is probably no point in resetting it at
vmrun emulation.
Joerg
--
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
