From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liran Alon Subject: Re: [PATCH v2] KVM: nVMX/nSVM: Don't intercept #UD when running L2 Date: Wed, 10 Jan 2018 15:01:49 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: , , , , , To: Return-path: Received: from userp2130.oracle.com ([156.151.31.86]:53434 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752447AbeAJXDV (ORCPT ); Wed, 10 Jan 2018 18:03:21 -0500 Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: ----- jmattson@google.com 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 Ra= vello 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 (w= as not yet queued) is based a bit on the code of this commit. Do you wish m= e to first wait that those patches will be queued and then I will create th= e revert for these (and resolve relevant conflicts) or that I will create t= he reverts for these on top of what is currently queued and you will resolv= e the conflicts resulting when applying VMware Backdoor support series? -Liran >=20 > On Fri, Dec 1, 2017 at 4:27 PM, Liran Alon > 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=C4=8Dm=C3=A1=C5=99 > 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 > >>>> Reviewed-by: Nikita Leshenko > >>>> Reviewed-by: Konrad Rzeszutek Wilk > >>>> Signed-off-by: Konrad Rzeszutek Wilk > >>>> --- > >>> > >>> > >>> Applied, thanks.