WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] nestedhvm: ASID emulation
From: Christoph Egger <Christoph.Egger@xxxxxxx>
Date: Wed, 13 Apr 2011 16:26:33 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 13 Apr 2011 07:57:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9CB6336.2C9FB%keir@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>
References: <C9CB6336.2C9FB%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.2.13) Gecko/20110202 Lightning/1.0b3pre Thunderbird/3.1.7
On 04/13/11 15:27, Keir Fraser wrote:
On 13/04/2011 11:37, "Christoph Egger"<Christoph.Egger@xxxxxxx>  wrote:


Implement ASID emulation.
This allows the l1 guest to run the l2 guest using hw ASID.

Signed-off-by: Christoph Egger<Christoph.Egger@xxxxxxx>

First, how much of a win is this compared with what we do currently?

We talk about a win of about 1000 cycles per VMRUN and another 1000 cycles per VMEXIT emulation.

That's a speedup of about 10% for each VMRUN and about 20% for each VMEXIT emulation.


Second, the two-asids-per-vcpu allocation scheme in
hvm_asid_handle_vmenter() looks broken. I mean, consider this comment:
   /* When asid generation changed last time when we were
    * were going to run l1 guest then next_asid<= nv->nv_n2asid. */

Oh, the 2nd 'were' should be removed.

I don't see how you can assert this to be true. Arbitrary generations can
have passed, and next_asid incremented to an arbitrary value, since the last
time you allocated nv_n2asid.

There are different cases to handle:

1. nestedhvm is disabled.

In this case, 'run_n2guest' is always false then the function should
have the old behaviour across multiple VMRUNs.

2. nestedhvm is enabled and we are going to run l1 guest

We run the l2 guest in the last call. The asid generation may have
changed by then. In this case the current nv_n1asid number is stale
and the value of data->next_asid is <= of nv->nv_n1asid.
The the value of nv->nv_n1asid is valid data->next_asid is
larger than nv->nv_n1asid. In this case just reuse the same hw ASID
that has been used from the last VMEXIT emulation.

3. nestedhvm is enabled and we are going to run l1 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 l2 guest.

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


--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel