x86/EPT: force re-evaluation of memory type as necessary
authorJan Beulich <jbeulich@suse.com>
Thu, 10 Apr 2014 14:01:41 +0000 (16:01 +0200)
committerJan Beulich <jbeulich@suse.com>
Thu, 10 Apr 2014 14:01:41 +0000 (16:01 +0200)
commitaa9114edd97b292cd89b3616e3f2089471fd2201
treedc15f1298cca707a17bc744b8aa50038a4170ba3
parent4eb9c9b90ccba96f3160ab830ad0888f99bdae0e
x86/EPT: force re-evaluation of memory type as necessary

The main goal here is to drop the bogus dependency of
epte_get_entry_emt() on d->arch.hvm_domain.params[HVM_PARAM_IDENT_PT].

Any change to state influencing epte_get_entry_emt()'s decision needs
to result in re-calculation. Do this by using the EPT_MISCONFIG VM
exit, storing an invalid memory type into EPT's emt field (leaving the
IOMMU, which doesn't care about memory types, unaffected).

This is being done in a hierarchical manner to keep execution time
down: Initially only the top level directory gets invalidated this way.
Upon access, the involved intermediate page table levels get cleared
back to zero, and the leaf entry gets its field properly set. For 4k
leaves all other entries in the same directory also get processed to
amortize the cost of the extra VM exit (which halved the number of
these VM exits in my testing).

This restoring can result in spurious EPT_MISCONFIG VM exits (since
two vCPU-s may access addresses involving identical page table
structures). Rather than simply returning in such cases (and risking
that such a VM exit results from a real mis-configuration, which
would then result in an endless loop rather than killing the VM), a
per-vCPU flag is being introduced indicating when such a spurious VM
exit might validly happen - if another one occurs right after VM re-
entry, the flag would generally end up being clear, causing the VM
to be killed as before on such VM exits.

Note that putting a reserved memory type value in the EPT structures
isn't formally sanctioned by the specification. Intel isn't willing to
adjust the specification to make this or a similar use of the
EPT_MISCONFIG VM exit formally possible, but they have indicated that
us using this is low risk wrt forward compatibility.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
xen/arch/x86/domctl.c
xen/arch/x86/hvm/hvm.c
xen/arch/x86/hvm/mtrr.c
xen/arch/x86/hvm/vmx/vmx.c
xen/arch/x86/mm/p2m-ept.c
xen/arch/x86/mm/p2m.c
xen/common/domctl.c
xen/include/asm-x86/hvm/vmx/vmcs.h
xen/include/asm-x86/hvm/vmx/vmx.h
xen/include/asm-x86/mtrr.h
xen/include/asm-x86/p2m.h