From: Paolo Bonzini <pbonzini@redhat.com>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, linux-mm@kvack.org, luto@kernel.org,
peterz@infradead.org, dave.hansen@intel.com,
sean.j.christopherson@intel.com, keescook@chromium.org
Cc: kristen@linux.intel.com, deneen.t.dock@intel.com
Subject: Re: [RFC PATCH 00/13] XOM for KVM guest userspace
Date: Fri, 4 Oct 2019 09:22:42 +0200 [thread overview]
Message-ID: <bc025a4f-2128-24ed-e5b7-76802f22cd53@redhat.com> (raw)
In-Reply-To: <20191003212400.31130-1-rick.p.edgecombe@intel.com>
On 03/10/19 23:23, Rick Edgecombe wrote:
> Since software would have previously received a #PF with the RSVD error code
> set, when the HW encountered any set bits in the region 51 to M, there was some
> internal discussion on whether this should have a virtual MSR for the OS to turn
> it on only if the OS knows it isn't relying on this behavior for bit M. The
> argument against needing an MSR is this blurb from the Intel SDM about reserved
> bits:
> "Bits reserved in the paging-structure entries are reserved for future
> functionality. Software developers should be aware that such bits may be used in
> the future and that a paging-structure entry that causes a page-fault exception
> on one processor might not do so in the future."
>
> So in the current patchset there is no MSR write required for the guest to turn
> on this feature. It will have this behavior whenever qemu is run with
> "-cpu +xo".
I think the part of the manual that you quote is out of date. Whenever
Intel has "unreserved" bits in the page tables they have done that only
if specific bits in CR4 or EFER or VMCS execution controls are set; this
is a good thing, and I'd really like it to be codified in the SDM.
The only bits for which this does not (and should not) apply are indeed
bits 51:MAXPHYADDR. But the SDM makes it clear that bits 51:MAXPHYADDR
are reserved, hence "unreserving" bits based on just a QEMU command line
option would be against the specification. So, please don't do this and
introduce an MSR that enables the feature.
Paolo
next prev parent reply other threads:[~2019-10-04 7:22 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 21:23 [RFC PATCH 00/13] XOM for KVM guest userspace Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 01/13] kvm: Enable MTRR to work with GFNs with perm bits Rick Edgecombe
2019-10-14 6:47 ` Yu Zhang
2019-10-14 18:44 ` Edgecombe, Rick P
2019-10-03 21:23 ` [RFC PATCH 02/13] kvm: Add support for X86_FEATURE_KVM_XO Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 03/13] kvm: Add XO memslot type Rick Edgecombe
2019-10-04 7:27 ` Paolo Bonzini
2019-10-04 19:06 ` Edgecombe, Rick P
2019-10-06 16:15 ` Paolo Bonzini
2019-10-03 21:23 ` [RFC PATCH 04/13] kvm, vmx: Add support for gva exit qualification Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 05/13] kvm: Add #PF injection for KVM XO Rick Edgecombe
2019-10-04 7:42 ` Paolo Bonzini
2019-10-04 19:11 ` Edgecombe, Rick P
2019-10-03 21:23 ` [RFC PATCH 06/13] kvm: Add KVM_CAP_EXECONLY_MEM Rick Edgecombe
2019-10-04 7:24 ` Paolo Bonzini
2019-10-04 19:11 ` Edgecombe, Rick P
2019-10-03 21:23 ` [RFC PATCH 07/13] kvm: Add docs for KVM_CAP_EXECONLY_MEM Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 08/13] x86/boot: Rename USE_EARLY_PGTABLE_L5 Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 09/13] x86/cpufeature: Add detection of KVM XO Rick Edgecombe
2019-10-29 23:33 ` Kees Cook
2019-10-29 23:52 ` Edgecombe, Rick P
2019-10-30 14:55 ` Sean Christopherson
2019-10-30 21:02 ` Edgecombe, Rick P
2019-10-03 21:23 ` [RFC PATCH 10/13] x86/mm: Add NR page bit for " Rick Edgecombe
2019-10-04 7:33 ` Paolo Bonzini
2019-10-03 21:23 ` [RFC PATCH 11/13] x86, ptdump: Add NR bit to page table dump Rick Edgecombe
2019-10-03 21:23 ` [RFC PATCH 12/13] mmap: Add XO support for KVM XO Rick Edgecombe
2019-10-04 7:34 ` Paolo Bonzini
2019-10-04 19:12 ` Edgecombe, Rick P
2019-10-03 21:24 ` [RFC PATCH 13/13] x86/Kconfig: Add Kconfig for KVM based XO Rick Edgecombe
2019-10-29 23:36 ` Kees Cook
2019-10-30 0:01 ` Edgecombe, Rick P
2019-10-30 18:36 ` Kees Cook
2019-10-04 7:22 ` Paolo Bonzini [this message]
2019-10-04 19:03 ` [RFC PATCH 00/13] XOM for KVM guest userspace Edgecombe, Rick P
2019-10-04 14:56 ` Andy Lutomirski
2019-10-04 20:09 ` Edgecombe, Rick P
2019-10-05 1:33 ` Andy Lutomirski
2019-10-07 18:14 ` Edgecombe, Rick P
2019-10-29 23:40 ` Kees Cook
2019-10-30 0:27 ` Edgecombe, Rick P
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=bc025a4f-2128-24ed-e5b7-76802f22cd53@redhat.com \
--to=pbonzini@redhat.com \
--cc=dave.hansen@intel.com \
--cc=deneen.t.dock@intel.com \
--cc=keescook@chromium.org \
--cc=kristen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sean.j.christopherson@intel.com \
--cc=x86@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).