[help]: VPID tagged TLBs question.

[help]: VPID tagged TLBs question.

[Mukesh Rathor]

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

Re: [help]: VPID tagged TLBs question.

[Keir Fraser]

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

Re: [help]: VPID tagged TLBs question.

[Mukesh Rathor]

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

Re: [help]: VPID tagged TLBs question.

[Keir Fraser]

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
> 
>