From: Yang Weijiang <weijiang.yang@intel.com>
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, jmattson@google.com,
sean.j.christopherson@intel.com
Cc: yu.c.zhang@linux.intel.com, alazar@bitdefender.com,
edwin.zhai@intel.com, ssicleru@bitdefender.com,
Yang Weijiang <weijiang.yang@intel.com>
Subject: [PATCH v12 07/11] mmu: spp: Enable Lazy mode SPP protection
Date: Sat, 16 May 2020 20:55:03 +0800 [thread overview]
Message-ID: <20200516125507.5277-8-weijiang.yang@intel.com> (raw)
In-Reply-To: <20200516125507.5277-1-weijiang.yang@intel.com>
When SPP protection is set but the gfn->pfn mapping isn't there,
we need to check and mark SPP protection in EPT while
gfn->pfn mapping is being built, but the setup for SPPT is deferred
to handle_spp() handler.
From HW's capability, SPP only works for 4KB mappings, to apply
SPP protection for hugepage(2MB,1GB) cases, hugepage entries need
to be zapped before SPP set up. In tdp_page_fault(), there's check
for SPP protection before sets 4KB, 2MB or 1GB mapping, the target
is introducing least impact to hugepage setup, i.e., falls back to
most possible hugepage mapping.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
---
arch/x86/kvm/mmu/mmu.c | 19 +++++++++++++++++++
arch/x86/kvm/mmu/spp.c | 43 ++++++++++++++++++++++++++++++++++++++++++
arch/x86/kvm/mmu/spp.h | 2 ++
3 files changed, 64 insertions(+)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 270dd567272e..9d5a0eb3d24e 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3131,6 +3131,7 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
unsigned int access = sp->role.access;
int i, ret;
gfn_t gfn;
+ u32 *wp_bitmap;
gfn = kvm_mmu_page_get_gfn(sp, start - sp->spt);
slot = gfn_to_memslot_dirty_bitmap(vcpu, gfn, access & ACC_WRITE_MASK);
@@ -3144,6 +3145,13 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
for (i = 0; i < ret; i++, gfn++, start++) {
mmu_set_spte(vcpu, start, access, 0, sp->role.level, gfn,
page_to_pfn(pages[i]), true, true);
+ if (vcpu->kvm->arch.spp_active) {
+ wp_bitmap = gfn_to_subpage_wp_info(slot, gfn);
+ if (wp_bitmap && *wp_bitmap != FULL_SPP_ACCESS)
+ kvm_spp_mark_protection(vcpu->kvm,
+ gfn,
+ *wp_bitmap);
+ }
put_page(pages[i]);
}
@@ -3336,6 +3344,15 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, int write,
map_writable);
direct_pte_prefetch(vcpu, it.sptep);
++vcpu->stat.pf_fixed;
+ if (level == PT_PAGE_TABLE_LEVEL) {
+ int ret;
+ u32 access;
+
+ ret = kvm_spp_get_permission(vcpu->kvm, gfn, 1, &access);
+ if (ret == 1 && access != FULL_SPP_ACCESS)
+ kvm_spp_mark_protection(vcpu->kvm, gfn, access);
+ }
+
return ret;
}
@@ -4125,6 +4142,8 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
if (lpage_disallowed)
max_level = PT_PAGE_TABLE_LEVEL;
+ check_spp_protection(vcpu, gfn, &max_level);
+
r = fast_page_fault(vcpu, gpa, error_code);
if (r != RET_PF_INVALID)
diff --git a/arch/x86/kvm/mmu/spp.c b/arch/x86/kvm/mmu/spp.c
index bb8f298d72da..8f89df57da7c 100644
--- a/arch/x86/kvm/mmu/spp.c
+++ b/arch/x86/kvm/mmu/spp.c
@@ -433,6 +433,49 @@ int kvm_spp_mark_protection(struct kvm *kvm, u64 gfn, u32 access)
return ret;
}
+static bool is_spp_protected(struct kvm_memory_slot *slot, gfn_t gfn, int level)
+{
+ int page_num = KVM_PAGES_PER_HPAGE(level);
+ u32 *access;
+ gfn_t gfn_max;
+
+ gfn &= ~(page_num - 1);
+ gfn_max = gfn + page_num - 1;
+ for (; gfn <= gfn_max; gfn++) {
+ access = gfn_to_subpage_wp_info(slot, gfn);
+ if (access && *access != FULL_SPP_ACCESS)
+ return true;
+ }
+ return false;
+}
+
+void check_spp_protection(struct kvm_vcpu *vcpu, gfn_t gfn,
+ int *max_level)
+{
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_memory_slot *slot;
+ bool protected;
+
+ if (!kvm->arch.spp_active)
+ return;
+
+ slot = gfn_to_memslot(kvm, gfn);
+
+ if (!slot)
+ return;
+
+ protected = is_spp_protected(slot, gfn, PT_DIRECTORY_LEVEL);
+
+ if (protected) {
+ *max_level = PT_PAGE_TABLE_LEVEL;
+ } else if (*max_level == PT_PDPE_LEVEL &&
+ is_spp_protected(slot, gfn, PT_PDPE_LEVEL)) {
+ *max_level = PT_DIRECTORY_LEVEL;
+ }
+
+ return;
+}
+
int kvm_vm_ioctl_get_subpages(struct kvm *kvm,
u64 gfn,
u32 npages,
diff --git a/arch/x86/kvm/mmu/spp.h b/arch/x86/kvm/mmu/spp.h
index c3588c20be52..e0541901ec41 100644
--- a/arch/x86/kvm/mmu/spp.h
+++ b/arch/x86/kvm/mmu/spp.h
@@ -11,6 +11,8 @@ int kvm_spp_get_permission(struct kvm *kvm, u64 gfn, u32 npages,
int kvm_spp_set_permission(struct kvm *kvm, u64 gfn, u32 npages,
u32 *access_map);
int kvm_spp_mark_protection(struct kvm *kvm, u64 gfn, u32 access);
+void check_spp_protection(struct kvm_vcpu *vcpu, gfn_t gfn,
+ int *max_level);
int kvm_vm_ioctl_get_subpages(struct kvm *kvm,
u64 gfn,
u32 npages,
--
2.17.2
next prev parent reply other threads:[~2020-05-16 12:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-16 12:54 [PATCH v12 00/11] Enable Sub-Page Write Protection Support Yang Weijiang
2020-05-16 12:54 ` [PATCH v12 01/11] Documentation: Add EPT based Subpage Protection and related APIs Yang Weijiang
2020-05-16 12:54 ` [PATCH v12 02/11] mmu: spp: Add a new header file to put definitions shared by MMU and SPP Yang Weijiang
2020-05-16 12:54 ` [PATCH v12 03/11] mmu: spp: Implement SPPT setup functions Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 04/11] mmu: spp: Implement functions to {get|set}_subpage permission Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 05/11] x86: spp: Introduce user-space SPP IOCTLs Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 06/11] vmx: spp: Handle SPP induced vmexit and EPT violation Yang Weijiang
2020-05-16 12:55 ` Yang Weijiang [this message]
2020-05-16 12:55 ` [PATCH v12 08/11] mmu: spp: Re-enable SPP protection when EPT mapping changes Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 09/11] x86: spp: Add SPP protection check in instruction emulation Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 10/11] vmx: spp: Initialize SPP bitmap and SPP protection Yang Weijiang
2020-05-16 12:55 ` [PATCH v12 11/11] kvm: selftests: selftest for Sub-Page protection Yang Weijiang
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=20200516125507.5277-8-weijiang.yang@intel.com \
--to=weijiang.yang@intel.com \
--cc=alazar@bitdefender.com \
--cc=edwin.zhai@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=ssicleru@bitdefender.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).