Hi, (Assume VPID is available and enabled.) I''m trying to figure the TLB stuff with VPIDs. I understand from the poorly written chapter in the intel manual that if an HVM vcpu is running then only the TLBs tagged with the vcpu.VPID will be used. If xen or a PV guest is running, then VPID 0 TLBs are what will be used. Now I understand the hvm_asid_flush_vcpu upon new guest cr3, will jsut create a new asid/vpid, so the older vcpu.vpid tlb entries will just not be used. 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? thanks Mukesh
On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> 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. -- Keir
On Thu, 26 Apr 2012 08:23:29 +0100 Keir Fraser <keir.xen@gmail.com> wrote:> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> 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
On 28/04/2012 02:25, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:> On Thu, 26 Apr 2012 08:23:29 +0100 > Keir Fraser <keir.xen@gmail.com> wrote: > >> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@oracle.com> 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?Try lashing it up and measure it. :-) My guess would be that it is not worth it. Our current algorithm minimises INVVPID instructions, just eats through the VPID space instead. Depending on the cost of INVVPID, versus the cost of having never-used-again stale tagged entries clogging up the TLB, our algorithm may be a bit better or worse than one that more aggressively uses INVVPID. My guess (which is only a guess!) is that the difference will be totally insignificant and unmeasurable. -- Keir> thanks, > Mukesh > >