From: Jim Mattson <jmattson@google.com>
To: Oliver Upton <oupton@google.com>
Cc: Jan Kiszka <jan.kiszka@web.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kvm list <kvm@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [FYI PATCH 1/3] KVM: nVMX: Don't emulate instructions in guest mode
Date: Sat, 29 Feb 2020 11:00:44 -0800 [thread overview]
Message-ID: <CALMp9eRETy1RLWHWKtFHqpcpFHbQKtPgJHDD_N+LPzaUPx-Jvg@mail.gmail.com> (raw)
In-Reply-To: <CAOQ_QshE7SMX2cO7H+21Fkdpg53oE2D3xrHPJHR_MCfH4r9QCQ@mail.gmail.com>
On Sat, Feb 29, 2020 at 10:33 AM Oliver Upton <oupton@google.com> wrote:
>
> Hi Jan,
>
> On Sat, Feb 29, 2020 at 10:00 AM Jan Kiszka <jan.kiszka@web.de> wrote:
> > Is this expected to cause regressions on less common workloads?
> > Jailhouse as L1 now fails when Linux as L2 tries to boot a CPU: L2-Linux
> > gets a triple fault on load_current_idt() in start_secondary(). Only
> > bisected so far, didn't debug further.
>
> I'm guessing that Jailhouse doesn't use 'descriptor table exiting', so
> when KVM gets the corresponding exit from L2 the emulation burden is
> on L0. We now refuse the emulation, which kicks a #UD back to L2. I
> can get a patch out quickly to address this case (like the PIO exiting
> one that came in this series) but the eventual solution is to map
> emulator intercept checks into VM-exits + call into the
> nested_vmx_exit_reflected() plumbing.
If Jailhouse doesn't use descriptor table exiting, why is L0
intercepting descriptor table instructions? Is this just so that L0
can partially emulate UMIP on hardware that doesn't support it?
next prev parent reply other threads:[~2020-02-29 19:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 18:56 [FYI PATCH 0/3] CVE-2020-2732 Paolo Bonzini
2020-02-24 18:56 ` [FYI PATCH 1/3] KVM: nVMX: Don't emulate instructions in guest mode Paolo Bonzini
2020-02-29 18:00 ` Jan Kiszka
2020-02-29 18:33 ` Oliver Upton
2020-02-29 19:00 ` Jim Mattson [this message]
2020-02-29 19:21 ` Jan Kiszka
2020-02-29 20:17 ` Jim Mattson
2020-02-29 20:36 ` Jan Kiszka
2020-02-24 18:56 ` [FYI PATCH 2/3] KVM: nVMX: Refactor IO bitmap checks into helper function Paolo Bonzini
2020-02-24 18:56 ` [FYI PATCH 3/3] KVM: nVMX: Check IO instruction VM-exit conditions Paolo Bonzini
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=CALMp9eRETy1RLWHWKtFHqpcpFHbQKtPgJHDD_N+LPzaUPx-Jvg@mail.gmail.com \
--to=jmattson@google.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).