[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [help]: VPID tagged TLBs question.
- To: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
- From: Keir Fraser <keir.xen@xxxxxxxxx>
- Date: Sat, 28 Apr 2012 06:45:20 +0100
- Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
- Delivery-date: Sat, 28 Apr 2012 05:46:02 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=40S2Jmcd/C/yIm9K3qrdjKQz3VWqC+CIk4I5x7kMmWM=; b=afCmiUd0W3iVKD2k7v61a1lraPL+R1ZPoGguYCcBO3EFuaYgRXSa/WA5Uq+0kJm2Y9 0ngeqG7U9vsWovEjZimgFm5Gs4EZhtqlIq/Np2P6w1Wexx3hYh438NHLhFe01uRAQKtf cmHxF8KGNIrDUMeggFGTueBZTfX4dYgOYRdEupG/ESi6sYJZJPlPqwL4dBetndF0DNeG j0okecpmESFj8ViY6BdnB3Nbv2sJ1sc8OR/PY4z6iM590Zcd5ZmmkhRB/t5LPavLMA56 Wk5g2WLFB0j266SoGt+kn6C++2HHOd1qejm1qhYs1QzBclrsFk4FgpC8NPTuDvGL17U+ Ix6A==
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
- Thread-index: Ac0lAhjPQFohlqlX6UKIAejyrNDtgQ==
- Thread-topic: [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 ->
>>> 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
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.
Xen-devel mailing list