From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [help]: VPID tagged TLBs question. Date: Fri, 27 Apr 2012 18:25:01 -0700 Message-ID: <20120427182501.197681ff@mantra.us.oracle.com> References: <20120425180729.6a8f7127@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: "Xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Thu, 26 Apr 2012 08:23:29 +0100 Keir Fraser wrote: > On 26/04/2012 02:07, "Mukesh Rathor" wrote: > > > However, I don't understand the use of hvm_asid_flush_core which > > it appears will cause all HVM vcpu's to get new vpid/asid, hence, > > discard all previously used VPID tagged TLBs. In particular, > > consider a PV guest: > > > > write_ptbase -> write_cr3 -> hvm_flush_guest_tlbs -> > > hvm_asid_flush_core(). > > > > Since the PV guest is only using VPID 0 tagged TLBs, why do we need > > to flush all TLBs for all HVM guests? > > It's just being conservative, as callers of write_cr3 may assume that > the TLB is entirely flushed, for all guests. Well, for write_cr3 path at least, we just need to invalidate all TLBs in the local pcpu. So it seems for this path we could just do invvpid with type 2, ie, invalidate all vpids except 0. Prob also need to do 'invept 2'. what do you think, worth it? thanks, Mukesh