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

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



On 04/13/11 17:05, Keir Fraser wrote:
On 13/04/2011 15:26, "Christoph Egger"<Christoph.Egger@xxxxxxx>  wrote:

On 04/13/11 15:27, Keir Fraser wrote:
On 13/04/2011 11:37, "Christoph Egger"<Christoph.Egger@xxxxxxx>   wrote:

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.

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.


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.

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






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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.