| Message ID | 20190814070403.6588-1-weijiang.yang@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enable Sub-page Write Protection Support | expand |
On 14/08/19 09:03, Yang Weijiang wrote: > EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows > Virtual Machine Monitor(VMM) to specify write-permission for guest > physical memory at a sub-page(128 byte) granularity. When this > capability is enabled, the CPU enforces write-access check for sub-pages > within a 4KB page. > > The feature is targeted to provide fine-grained memory protection for > usages such as device virtualization, memory check-point and VM > introspection etc. > > SPP is active when the "sub-page write protection" (bit 23) is 1 in > Secondary VM-Execution Controls. The feature is backed with a Sub-Page > Permission Table(SPPT), SPPT is referenced via a 64-bit control field > called Sub-Page Permission Table Pointer (SPPTP) which contains a > 4K-aligned physical address. > > Right now, only 4KB physical pages are supported for SPP. To enable SPP > for certain physical page, we need to first make the physical page > write-protected, then set bit 61 of the corresponding EPT leaf entry. > While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset > physical address to find out the sub-page permissions at the leaf entry. > If the corresponding bit is set, write to sub-page is permitted, > otherwise, SPP induced EPT violation is generated. Still no testcases? Paolo
On Wed, Aug 14, 2019 at 02:36:30PM +0200, Paolo Bonzini wrote: > On 14/08/19 09:03, Yang Weijiang wrote: > > EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows > > Virtual Machine Monitor(VMM) to specify write-permission for guest > > physical memory at a sub-page(128 byte) granularity. When this > > capability is enabled, the CPU enforces write-access check for sub-pages > > within a 4KB page. > > > > The feature is targeted to provide fine-grained memory protection for > > usages such as device virtualization, memory check-point and VM > > introspection etc. > > > > SPP is active when the "sub-page write protection" (bit 23) is 1 in > > Secondary VM-Execution Controls. The feature is backed with a Sub-Page > > Permission Table(SPPT), SPPT is referenced via a 64-bit control field > > called Sub-Page Permission Table Pointer (SPPTP) which contains a > > 4K-aligned physical address. > > > > Right now, only 4KB physical pages are supported for SPP. To enable SPP > > for certain physical page, we need to first make the physical page > > write-protected, then set bit 61 of the corresponding EPT leaf entry. > > While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset > > physical address to find out the sub-page permissions at the leaf entry. > > If the corresponding bit is set, write to sub-page is permitted, > > otherwise, SPP induced EPT violation is generated. > > Still no testcases? > > Paolo Hi, Paolo, The testcases are included in selftest: https://lkml.org/lkml/2019/6/18/1197
On 14/08/19 16:02, Yang Weijiang wrote: > On Wed, Aug 14, 2019 at 02:36:30PM +0200, Paolo Bonzini wrote: >> On 14/08/19 09:03, Yang Weijiang wrote: >>> EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows >>> Virtual Machine Monitor(VMM) to specify write-permission for guest >>> physical memory at a sub-page(128 byte) granularity. When this >>> capability is enabled, the CPU enforces write-access check for sub-pages >>> within a 4KB page. >>> >>> The feature is targeted to provide fine-grained memory protection for >>> usages such as device virtualization, memory check-point and VM >>> introspection etc. >>> >>> SPP is active when the "sub-page write protection" (bit 23) is 1 in >>> Secondary VM-Execution Controls. The feature is backed with a Sub-Page >>> Permission Table(SPPT), SPPT is referenced via a 64-bit control field >>> called Sub-Page Permission Table Pointer (SPPTP) which contains a >>> 4K-aligned physical address. >>> >>> Right now, only 4KB physical pages are supported for SPP. To enable SPP >>> for certain physical page, we need to first make the physical page >>> write-protected, then set bit 61 of the corresponding EPT leaf entry. >>> While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset >>> physical address to find out the sub-page permissions at the leaf entry. >>> If the corresponding bit is set, write to sub-page is permitted, >>> otherwise, SPP induced EPT violation is generated. >> >> Still no testcases? >> >> Paolo > > Hi, Paolo, > The testcases are included in selftest: https://lkml.org/lkml/2019/6/18/1197 > Good, thanks! Paolo
EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows Virtual Machine Monitor(VMM) to specify write-permission for guest physical memory at a sub-page(128 byte) granularity. When this capability is enabled, the CPU enforces write-access check for sub-pages within a 4KB page. The feature is targeted to provide fine-grained memory protection for usages such as device virtualization, memory check-point and VM introspection etc. SPP is active when the "sub-page write protection" (bit 23) is 1 in Secondary VM-Execution Controls. The feature is backed with a Sub-Page Permission Table(SPPT), SPPT is referenced via a 64-bit control field called Sub-Page Permission Table Pointer (SPPTP) which contains a 4K-aligned physical address. Right now, only 4KB physical pages are supported for SPP. To enable SPP for certain physical page, we need to first make the physical page write-protected, then set bit 61 of the corresponding EPT leaf entry. While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset physical address to find out the sub-page permissions at the leaf entry. If the corresponding bit is set, write to sub-page is permitted, otherwise, SPP induced EPT violation is generated. This patch serial passed SPP function test and selftest on Ice-Lake platform. Please refer to the SPP introduction document in this patch set and Intel SDM for details: Intel SDM: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf SPP selftest patch: https://lkml.org/lkml/2019/6/18/1197 Previous patch: https://lkml.org/lkml/2019/6/6/695 Patch 1: Introduction to SPP. Patch 2: Add SPP related flags and control bits. Patch 3: Functions for SPPT setup. Patch 4: Add SPP access bitmaps for memslots. Patch 5: Low level implementation of SPP operations. Patch 6: Implement User space access IOCTLs. Patch 7: Handle SPP induced VMExit and EPT violation. Patch 8: Enable lazy mode SPPT setup. Patch 9: Handle memory remapping and reclaim. Change logs: V3 -> v4: 1. Modified documentation to make it consistent with patches. 2. Allocated SPPT root page in init_spp() instead of vmx_set_cr3() to avoid SPPT miss error. 3. Added back co-developers and sign-offs. V2 -> V3: 1. Rebased patches to kernel 5.1 release 2. Deferred SPPT setup to EPT fault handler if the page is not available while set_subpage() is being called. 3. Added init IOCTL to reduce extra cost if SPP is not used. 4. Refactored patch structure, cleaned up cross referenced functions. 5. Added code to deal with memory swapping/migration/shrinker cases. V2 -> V1: 1. Rebased to 4.20-rc1 2. Move VMCS change to a separated patch. 3. Code refine and Bug fix Yang Weijiang (9): Documentation: Introduce EPT based Subpage Protection KVM: VMX: Add control flags for SPP enabling KVM: VMX: Implement functions for SPPT paging setup KVM: VMX: Introduce SPP access bitmap and operation functions KVM: VMX: Add init/set/get functions for SPP KVM: VMX: Introduce SPP user-space IOCTLs KVM: VMX: Handle SPP induced vmexit and page fault KVM: MMU: Enable Lazy mode SPPT setup KVM: MMU: Handle host memory remapping and reclaim Documentation/virtual/kvm/spp_kvm.txt | 173 ++++++++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/kvm_host.h | 26 +- arch/x86/include/asm/vmx.h | 10 + arch/x86/include/uapi/asm/vmx.h | 2 + arch/x86/kernel/cpu/intel.c | 4 + arch/x86/kvm/mmu.c | 480 ++++++++++++++++++++++++++ arch/x86/kvm/mmu.h | 1 + arch/x86/kvm/vmx/capabilities.h | 5 + arch/x86/kvm/vmx/vmx.c | 129 +++++++ arch/x86/kvm/x86.c | 141 ++++++++ include/linux/kvm_host.h | 9 + include/uapi/linux/kvm.h | 17 + 13 files changed, 997 insertions(+), 1 deletion(-) create mode 100644 Documentation/virtual/kvm/spp_kvm.txt