Enabling Extended Page Table(EPT) for VMX
cover Enabling Extended Page Table(EPT) for VMX
Hi, Avi
Here is the patchset which enabling EPT for VMX. We tested it with 32e host, and it works well on Linux, Windows, also SMP with kernel build, though the X Window and windows need a patch for qemu to solve the dirty bitmap problem.
The format of EPT entry is different from the page table, so we would create EPT page table separately.
The patchset would support swap along with the mmu_notifier. But the patch of mmu_notifier is not stable in our test (with shadow), so we didn't test it with EPT. But the interface and the function has been in the patch, we can add the support easily when mmu_notifier is ready.
Any comments are welcome!
Here is the diffstat for kernel space:
arch/x86/kvm/mmu.c | 71 ++++++- arch/x86/kvm/svm.c | 6 + arch/x86/kvm/vmx.c | 489 +++++++++++++++++++++++++++++++++++++++++++- arch/x86/kvm/vmx.h | 26 +++ arch/x86/kvm/x86.c | 1 + include/asm-x86/kvm_host.h | 21 ++ include/linux/kvm_host.h | 1 + virt/kvm/kvm_main.c | 3 +- 8 files changed, 606 insertions(+), 12 deletions(-)
Here for userspace:
qemu/hw/pc.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
Signature · 7 lines
Thanks Yang, Sheng ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 200802011619.17478.sheng.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Quoted 6 lines · Sheng
Hi, Avi
Here is the patchset which enabling EPT for VMX. We tested it with 32e host, and it works well on Linux, Windows, also SMP with kernel build, though the X Window and windows need a patch for qemu to solve the dirty bitmap problem.
Quoted 8 lines
The format of EPT entry is different from the page table, so we would create EPT page table separately.
The patchset would support swap along with the
mmu_notifier. But the patch ofmmu_notifieris not stable in our test (with shadow), so we didn't test it with EPT. But the interface and the function has been in the patch, we can add the support easily whenmmu_notifieris ready.
The completely separate path that EPT takes worries me. It means that memory aliasing, large pages (EPT supports large pages, right?), memory sharing, and other memory management issues need to be coded and maintained in parallel.
While the format of EPT is different from normal 64-bit ptes, it is quite similar:
Quoted 6 lines
(quoted diff) +6
-0+typedef union { + struct { + u64 r : 1, + w : 1, + x : 1, + emt : 3,
Review
Quoted 10 lines
(quoted diff) +10
-0+ rsvd_igmt : 1, + sp_avail : 1, + avail1 : 4, + addr_mfn : 45, + rsvd : 5, + avail2 : 2; + } fields; + u64 entry; +} epte_t; +
'r' is equivalent to the 'p' bit, since we never clear 'p' without clearing the rest of the pte
'w' is equivalent to a pte 'w'
'x' needs to be set all the time
what's 'emt'? memory type?
'sp_avail'? superpage? If so, I think it's even in the normal position. addr_mfn is equivalent to the pfn part of the pte
So with minor modifications, I think the regular mmu can be adapted to support ept, basically dropping dirty/accessed bit support and adding the fixed settings for the other bits.
Signature · 7 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/