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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
