From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: Re: [PATCHv6 1/2] x86/ept: invalidate guest physical mappings on VMENTER Date: Sun, 20 Dec 2015 06:51:55 +0000 Message-ID: References: <1450446634-8762-1-git-send-email-david.vrabel@citrix.com> <1450446634-8762-2-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aAXqh-0002ZF-UK for xen-devel@lists.xenproject.org; Sun, 20 Dec 2015 06:52:08 +0000 In-Reply-To: <1450446634-8762-2-git-send-email-david.vrabel@citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel , "xen-devel@lists.xenproject.org" Cc: George Dunlap , Andrew Cooper , Tim Deegan , Jan Beulich , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org > From: David Vrabel [mailto:david.vrabel@citrix.com] > 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 > Reviewed-by: George Dunlap Acked-by: Kevin Tian