This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] nestedhvm: ASID emulation

To: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] nestedhvm: ASID emulation
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Wed, 13 Apr 2011 17:22:30 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 13 Apr 2011 09:23:23 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=gZXy5lFaSMEp3igZ5POKc4O660tmU+kYtgR4DDXUJf8=; b=OMXGKEo1/4HBjheMVfn1Yju3T0aOlsOYWYmByMTbT2/PZOvTr/fz5+KEIxoB13c74A 44SOE+LMVpNGI0n9mT1sAzxh0vx+WPQpwRkHtboYEcksNq2PwbTv/NJ24nAAnZl0EZPD hicsN1ylo4EPYPozc8WSGWNCjiHGUgPNt4OvI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Hbl3+xmZiLUkVgKwQkPiLM0RYHZ3SpNSq7Vtxoo9/gmsOYT4D0uMgLTPhdEwzT4Kc3 XlqzK1pxd83doTjx6eGeer9irVLmvplw2ZGycWCT3sU2bvHMppkHWdgFRSS+3nmcT+KR 5cLZ/hLRjg3fizbEMWBiTLLi205q6qoFxdysA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DA5BEF4.3060504@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acv59vxHaWmV+oBSNEuiAccJlIbZTQ==
Thread-topic: [Xen-devel] [PATCH] nestedhvm: ASID emulation
User-agent: Microsoft-Entourage/
On 13/04/2011 16:19, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:

> On 04/13/11 17:05, Keir Fraser wrote:
>> On 13/04/2011 15:26, "Christoph Egger"<Christoph.Egger@xxxxxxx>  wrote:
>> Is this measurable on a macro benchmark?
> I measured this with xentrace while l2 guest is booting.
> The speedup is noticable on the end-user side just by the feeling on how
> fast the l2 guest reacts on user input.

Yikes. Does nestedhvm suck really badly then? I can't believe this patch
alone gets you from sucky to good performance. Is it an improvement from
sucky to not-quite-as-sucky?

>> I mean this looks like a micro-optimisation on a feature that noone is going
>> to use for serious performance work anyway.
>>> 4. nestedhvm is enabled and we are going to run l2 guest
>>> We run the l1 guest in the last call. The asid generation may have
>>> changed by then. In this case the current nv_n2asid number is stale
>>> and the value of data->next_asid is<= of nv->nv_n2asid.
>> How do you know for sure that next_asid will be<= nv_n2asid in this case?
>> What if other VCPUs have run meanwhile, and next_asid has been incremented
>> multiple times until it is greather than nv_n2asid?
> In that case  curr->arch.hvm_vcpu.asid_generation is not equal to
> data->core_asid_generation  and a new hw ASID number is assigned
> regardless of the values of data->next_asid and nv_n2asid.

What if nv_n2asid wast last assigned on a previous generation, but nv_n1asid
was assigned from the current generation? Then you'd have next_asid >
nv_n2asid, but nv_n2asid is stale.

 -- Keir

> Christoph
>>   -- Keir
>>> The the value of nv->nv_n2asid is valid if l1 guest doesn't change
>>> the virtual asid (= asid number in the virtual vmcb) and
>>> data->next_asid is larger than nv->nv_n2asid. In this case
>>> just reuse the same hw ASID that has been used from the last
>>> VMRUN emulation.
>>> 5. nestedhvm is enabled and we are going to run l2 guest again
>>> The same hw ASID should be reused unless the generation changed because
>>> the nestedp2m got flushed or the vcpu moved to a different physical cpu,
>>> for example.
>>> But the hw ASID number may never match the hw ASID used to run the l1 guest.
>>> In all cases we have to verify that the
>>>> I wouldn't bother fixing #2 unless there's a convincing answer for #1.
>>>>    -- Keir

Xen-devel mailing list