From: Liran Alon <liran.alon@oracle.com>
To: <jmattson@google.com>
Cc: <konrad.wilk@oracle.com>, <rkrcmar@redhat.com>,
<hofsass@google.com>, <pbonzini@redhat.com>,
<idan.brown@oracle.com>, <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: nVMX/nSVM: Don't intercept #UD when running L2
Date: Wed, 10 Jan 2018 15:01:49 -0800 (PST) [thread overview]
Message-ID: <ce93931b-8c8e-4cca-8a00-892e16e9f82f@default> (raw)
----- 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 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@oracle.com>
> 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@redhat.com>
> 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@oracle.com>
> >>>> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
> >>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>> ---
> >>>
> >>>
> >>> Applied, thanks.
next reply other threads:[~2018-01-10 23:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 23:01 Liran Alon [this message]
2018-01-11 10:34 ` [PATCH v2] KVM: nVMX/nSVM: Don't intercept #UD when running L2 Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2018-01-11 13:29 Liran Alon
2017-11-06 14:15 Liran Alon
2017-11-06 14:16 ` Paolo Bonzini
2017-11-07 1:23 ` Wanpeng Li
2017-11-10 21:37 ` Radim Krčmář
2017-12-01 23:00 ` Jim Mattson
2017-12-01 23:08 ` Jim Mattson
2017-12-02 0:27 ` Liran Alon
2018-01-10 19:56 ` Jim Mattson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce93931b-8c8e-4cca-8a00-892e16e9f82f@default \
--to=liran.alon@oracle.com \
--cc=hofsass@google.com \
--cc=idan.brown@oracle.com \
--cc=jmattson@google.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox