From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jim Mattson <jmattson@google.com>,
Chenyi Qiang <chenyi.qiang@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Joerg Roedel <joro@8bytes.org>, Xiaoyao Li <xiaoyao.li@intel.com>,
kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 6/7] KVM: X86: Expose PKS to guest and userspace
Date: Tue, 26 Jan 2021 11:56:49 -0800 [thread overview]
Message-ID: <YBB0AT6xfObR7A5l@google.com> (raw)
In-Reply-To: <c8f39e4e-75e1-8089-f8ef-9931ce14339f@redhat.com>
On Tue, Jan 26, 2021, Paolo Bonzini wrote:
> On 30/09/20 06:36, Sean Christopherson wrote:
> > > CR4.PKS is not in the list of CR4 bits that result in a PDPTE load.
> > > Since it has no effect on PAE paging, I would be surprised if it did
> > > result in a PDPTE load.
> > It does belong in the mmu_role_bits though;-)
> >
>
> Does it? We don't support PKU/PKS for shadow paging, and it's always zero
> for EPT. We only support enough PKU/PKS for emulation.
As proposed, yes. The PKU/PKS mask is tracked on a per-mmu basis, e.g. computed
in update_pkr_bitmask() and consumed in permission_fault() during emulation.
Omitting CR4.PKS from the extended role could let KVM reuse an MMU with the
wrong pkr_mask.
That being said, I don't think it needs a dedicated bit. IIUC, the logic is
PKU|PKS, with pkr_mask generation being PKU vs. PKS agnostic. The role could do
the same and smush the bits together, e.g.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3d6616f6f6ef..3bfca34f6ea2 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -293,7 +293,7 @@ union kvm_mmu_extended_role {
unsigned int cr0_pg:1;
unsigned int cr4_pae:1;
unsigned int cr4_pse:1;
- unsigned int cr4_pke:1;
+ unsigned int cr4_pkr:1;
unsigned int cr4_smap:1;
unsigned int cr4_smep:1;
unsigned int maxphyaddr:6;
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 79166288ed03..2774b85a36d5 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -4448,7 +4448,8 @@ static union kvm_mmu_extended_role kvm_calc_mmu_role_ext(struct kvm_vcpu *vcpu)
ext.cr4_smep = !!kvm_read_cr4_bits(vcpu, X86_CR4_SMEP);
ext.cr4_smap = !!kvm_read_cr4_bits(vcpu, X86_CR4_SMAP);
ext.cr4_pse = !!is_pse(vcpu);
- ext.cr4_pke = !!kvm_read_cr4_bits(vcpu, X86_CR4_PKE);
+ ext.cr4_pkr = !!kvm_read_cr4_bits(vcpu, X86_CR4_PKE) ||
+ !!kvm_read_cr4_bits(vcpu, X86_CR4_PKS);
ext.maxphyaddr = cpuid_maxphyaddr(vcpu);
ext.valid = 1;
Another option would be to move the tracking out of the MMU, e.g. make pkr_mask
per-vCPU and recalculate when CR4 changes. I think that would "just work", even
when nested VMs are in play?
next prev parent reply other threads:[~2021-01-27 13:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 8:48 [RFC 0/7] KVM: PKS Virtualization support Chenyi Qiang
2020-08-07 8:48 ` [RFC 1/7] KVM: VMX: Introduce PKS VMCS fields Chenyi Qiang
2020-08-10 23:17 ` Jim Mattson
2020-08-07 8:48 ` [RFC 2/7] KVM: VMX: Expose IA32_PKRS MSR Chenyi Qiang
2020-08-12 21:21 ` Jim Mattson
2020-08-13 5:42 ` Chenyi Qiang
2020-08-13 17:31 ` Jim Mattson
2020-08-18 7:27 ` Chenyi Qiang
2020-08-18 18:23 ` Jim Mattson
2020-08-22 3:28 ` Sean Christopherson
2021-01-26 18:01 ` Paolo Bonzini
2021-01-27 7:55 ` Chenyi Qiang
2021-02-01 9:53 ` Chenyi Qiang
2021-02-01 10:05 ` Paolo Bonzini
2020-08-07 8:48 ` [RFC 3/7] KVM: MMU: Rename the pkru to pkr Chenyi Qiang
2021-01-26 18:16 ` Paolo Bonzini
2020-08-07 8:48 ` [RFC 4/7] KVM: MMU: Refactor pkr_mask to cache condition Chenyi Qiang
2021-01-26 18:16 ` Paolo Bonzini
2021-01-27 3:14 ` Chenyi Qiang
2020-08-07 8:48 ` [RFC 5/7] KVM: MMU: Add support for PKS emulation Chenyi Qiang
2021-01-26 18:23 ` Paolo Bonzini
2021-01-27 3:00 ` Chenyi Qiang
2021-01-27 8:37 ` Paolo Bonzini
2020-08-07 8:48 ` [RFC 6/7] KVM: X86: Expose PKS to guest and userspace Chenyi Qiang
2020-08-13 19:04 ` Jim Mattson
2020-08-14 2:33 ` Chenyi Qiang
2020-09-30 4:36 ` Sean Christopherson
2021-01-26 18:24 ` Paolo Bonzini
2021-01-26 19:56 ` Sean Christopherson [this message]
2021-01-26 20:05 ` Paolo Bonzini
2020-08-07 8:48 ` [RFC 7/7] KVM: VMX: Enable PKS for nested VM Chenyi Qiang
2020-08-11 0:05 ` Jim Mattson
2020-08-12 15:00 ` Sean Christopherson
2020-08-12 18:32 ` Jim Mattson
2020-08-13 4:52 ` Chenyi Qiang
2020-08-13 17:52 ` Jim Mattson
2020-08-14 10:07 ` Chenyi Qiang
2020-08-14 17:34 ` 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=YBB0AT6xfObR7A5l@google.com \
--to=seanjc@google.com \
--cc=chenyi.qiang@intel.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=xiaoyao.li@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).