From: Sean Christopherson <sean.j.christopherson@intel.com>
To: John Allen <john.allen@amd.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, rkrcmar@redhat.com, vkuznets@redhat.com
Subject: Re: [PATCH v2] kvm/svm: PKU not currently supported
Date: Thu, 19 Dec 2019 12:32:14 -0800 [thread overview]
Message-ID: <20191219203214.GC6439@linux.intel.com> (raw)
In-Reply-To: <20191219201759.21860-1-john.allen@amd.com>
On Thu, Dec 19, 2019 at 02:17:59PM -0600, John Allen wrote:
> Current SVM implementation does not have support for handling PKU. Guests
> running on a host with future AMD cpus that support the feature will read
> garbage from the PKRU register and will hit segmentation faults on boot as
> memory is getting marked as protected that should not be. Ensure that cpuid
> from SVM does not advertise the feature.
>
> Signed-off-by: John Allen <john.allen@amd.com>
> ---
> v2:
> -Introduce kvm_x86_ops->pku_supported()
I like the v1 approach better, it's less code to unwind when SVM gains
support for virtualizaing PKU.
The existing cases of kvm_x86_ops->*_supported() in __do_cpuid_func() are
necessary to handle cases where it may not be possible to expose a feature
even though it's supported in hardware, host and KVM, e.g. VMX's separate
MSR-based features and PT's software control to hide it from guest. In
this case, hiding PKU is purely due to lack of support in KVM. The SVM
series to enable PKU can then delete a single line of SVM code instead of
having to go back in and do surgery on x86 and VMX.
next prev parent reply other threads:[~2019-12-19 20:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 20:17 [PATCH v2] kvm/svm: PKU not currently supported John Allen
2019-12-19 20:32 ` Sean Christopherson [this message]
2019-12-20 9:25 ` Paolo Bonzini
2019-12-23 15:21 ` John Allen
2020-01-18 20:03 ` 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=20191219203214.GC6439@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=vkuznets@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;
as well as URLs for NNTP newsgroup(s).