Re: [PATCH v2] KVM: nVMX/nSVM: Don't intercept #UD when running L2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- jmattson@xxxxxxxxxx wrote:

> Liran, Are you planning to submit reverts for ae1f57670703 and
> ac9b305caa0d?

Yes.
I just didn't had time to deal with this as I was busy with other Oracle Ravello specific issues.
I think reverting both commits is the right thing to do.

Paolo: Note that the VMware Backdoor support series we have patched here (was not yet queued) is based a bit on the code of this commit. Do you wish me to first wait that those patches will be queued and then I will create the revert for these (and resolve relevant conflicts) or that I will create the reverts for these on top of what is currently queued and you will resolve the conflicts resulting when applying VMware Backdoor support series?

-Liran

> 
> On Fri, Dec 1, 2017 at 4:27 PM, Liran Alon <LIRAN.ALON@xxxxxxxxxx>
> wrote:
> >
> >
> > On 02/12/17 01:00, Jim Mattson wrote:
> >>
> >> How does this change interact with commit 84cffe499b94 ("kvm:
> Emulate
> >> MOVBE")?
> >>
> >> If the hardware doesn't support MOVBE, but L0 sets
> CPUID.01H:ECX.MOVBE
> >> in L1's emulated CPUID information, then L1 is likely to pass that
> >> CPUID bit through to L2. L2 will expect MOVBE to work, but if L1
> >> doesn't intercept #UD, then any MOVBE instruction executed in L2
> will
> >> raise #UD, and the exception will be delivered in L2.
> >>
> >
> > Nice catch.
> >
> > When I considered the functionality of the original commit which I
> attempted
> > to fix (commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD while in
> guest
> > mode")), my patch made sense as a more complete and better fix.
> >
> > However, both my patch and the original patch don't seem to consider
> the
> > issue you present here. I completely agree.
> >
> > Maybe it was better just reverting my patch and commit ae1f57670703.
> I think
> > the attempt of that patch was to make L0 not simulate behaviour it
> simulates
> > for L1 in L2 as-well. but after reading your reply, I think that it
> is a
> > desired behaviour...
> >
> > -Liran
> >
> >
> >>
> >> On Fri, Nov 10, 2017 at 1:37 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx>
> wrote:
> >>>
> >>> 2017-11-06 16:15+0200, Liran Alon:
> >>>>
> >>>> When running L2, #UD should be intercepted by L1 or just
> forwarded
> >>>> directly to L2. It should not reach L0 x86 emulator.
> >>>> Therefore, set intercept for #UD only based on L1
> exception-bitmap.
> >>>>
> >>>> Also add WARN_ON_ONCE() on L0 #UD intercept handlers to make
> sure
> >>>> it is never reached while running L2.
> >>>>
> >>>> This improves commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD
> while
> >>>> in guest mode") by removing an unnecessary exit from L2 to L0 on
> #UD
> >>>> when L1 doesn't intercept it.
> >>>>
> >>>> In addition, SVM L0 #UD intercept handler doesn't handle
> correctly the
> >>>> case it is raised from L2. In this case, it should forward the
> #UD to
> >>>> guest instead of x86 emulator. As done in VMX #UD intercept
> handler.
> >>>> This commit fixes this issue as-well.
> >>>>
> >>>> Signed-off-by: Liran Alon <liran.alon@xxxxxxxxxx>
> >>>> Reviewed-by: Nikita Leshenko <nikita.leshchenko@xxxxxxxxxx>
> >>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >>>> ---
> >>>
> >>>
> >>> Applied, thanks.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux