From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "KVM: x86: WARN and reject loading KVM if NX is supported but not enabled"
Date: Wed, 21 Jul 2021 21:28:22 +0000 [thread overview]
Message-ID: <YPiRdiG0uFFNGtmN@google.com> (raw)
In-Reply-To: <20210713035944.l7qa7q4qsmqywg6u@linux.intel.com>
On Tue, Jul 13, 2021, Yu Zhang wrote:
> On Mon, Jul 12, 2021 at 02:36:53PM +0000, Sean Christopherson wrote:
> > On Mon, Jul 12, 2021, Yu Zhang wrote:
> > > Why do we need EFER in that case? Thanks! :)
> >
> > Because as you rightly remembered above, KVM always uses PAE paging for the guest,
> > even when the host is !PAE. And KVM also requires EFER.NX=1 for the guest when
> > using shadow paging to handle a potential SMEP and !WP case.
>
> Just saw this in update_transition_efer(), which now enables efer.nx in shadow
> unconditionally. But I guess the host kernel still needs to set efer.nx for
> !PAE(e.g. in head_32.S),
Yep, and that's what I messed up.
> because the guest may not touch efer at all. Is this correct?
KVM doesn't require EFER.NX "because the guest may not touch efer at all", it
requires EFER.NX to handle scenarios where KVM needs to make a guest page
!EXECUTABLE even if EFER is not exposed to the guest (thanks to SMEP && !WP).
prev parent reply other threads:[~2021-07-21 21:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 0:18 [PATCH] Revert "KVM: x86: WARN and reject loading KVM if NX is supported but not enabled" Sean Christopherson
2021-07-08 16:17 ` Paolo Bonzini
2021-07-09 17:21 ` Sean Christopherson
2021-07-09 17:32 ` Paolo Bonzini
2021-07-12 7:52 ` Yu Zhang
2021-07-12 14:36 ` Sean Christopherson
2021-07-13 3:59 ` Yu Zhang
2021-07-21 21:28 ` Sean Christopherson [this message]
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=YPiRdiG0uFFNGtmN@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=yu.c.zhang@linux.intel.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;
as well as URLs for NNTP newsgroup(s).