[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [help]: VPID tagged TLBs question.

On 28/04/2012 02:25, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:

> On Thu, 26 Apr 2012 08:23:29 +0100
> Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 
>> On 26/04/2012 02:07, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> 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
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel