x86/ept: invalidate guest physical mappings on VMENTER
authorDavid Vrabel <david.vrabel@citrix.com>
Mon, 21 Dec 2015 12:36:41 +0000 (13:36 +0100)
committerJan Beulich <jbeulich@suse.com>
Mon, 21 Dec 2015 12:36:41 +0000 (13:36 +0100)
commit8eb2235599925b508bcbeb3402aba21fa2c266fd
tree5f93e02b496ead305631dd3a97fbdcbce93191a7
parent8916fcf4577dbaf6e0a2f7b447e17e8820b22107
x86/ept: invalidate guest physical mappings on VMENTER

If a guest allocates a page and the tlbflush_timestamp on the page
indicates that a TLB flush of the previous owner is required, only the
linear and combined mappings are invalidated.  The guest-physical
mappings are not invalidated.

This is currently safe because the EPT code ensures that the
guest-physical and combined mappings are invalidated /before/ the page
is freed.  However, this prevents us from deferring the EPT invalidate
until after the page is freed (e.g., to defer the invalidate until the
p2m locks are released).

The TLB flush that may be done after allocating page already causes
the original guest to VMEXIT, thus on VMENTER we can do an INVEPT if
one is pending.

This means __ept_sync_domain() need not do anything and the thus the
on_selected_cpu() call does not need to wait for as long.

ept_sync_domain() now marks all PCPUs as needing to be invalidated,
including PCPUs that the domain has not run on.  We still only IPI
those PCPUs that are active so this does not result in any more INVEPT
calls.

We do not attempt to track when PCPUs may have cached translations
because the only safe way to clear this per-CPU state is if
immediately after an invalidate the PCPU is not active (i.e., the PCPU
is not in d->domain_dirty_cpumask).  Since we only invalidate on
VMENTER or by IPIing active PCPUs this can never happen.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
xen/arch/x86/hvm/vmx/vmx.c
xen/arch/x86/mm/p2m-ept.c
xen/include/asm-x86/hvm/vmx/vmcs.h