[RFC][PATCH 0/7]Enabling Extended Page Table(EPT) for VMX

[RFC][PATCH 0/7]Enabling Extended Page Table(EPT) for VMX

[Yang, 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. 

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(-)

-- 
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/

Re: [RFC][PATCH 0/7]Enabling Extended Page Table(EPT) for VMX

[Avi Kivity]

Yang, Sheng wrote:
> 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.
>   

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:

> +typedef union {
> +	struct {
> +		u64 r		:   1,
> +		    w           :   1,
> +		    x           :   1,
> +		    emt         :   3,
> +		    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.

-- 
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/