Re: [PATCH] nestedhvm: ASID emulation

[Keir Fraser <keir.xen@gmail.com>]

On 13/04/2011 15:26, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> On 04/13/11 15:27, Keir Fraser wrote:
>> On 13/04/2011 11:37, "Christoph Egger"<Christoph.Egger@amd.com>  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 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?

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