[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv6 1/2] x86/ept: invalidate guest physical mappings on VMENTER
> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx] > Sent: Friday, December 18, 2015 9:51 PM > > 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@xxxxxxxxxx> > Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |