Re: [PATCH] nestedhvm: ASID emulation

[Keir Fraser <keir@xen.org>]

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

> On 04/14/11 16:43, Keir Fraser wrote:
>> On 14/04/2011 15:01, "Christoph Egger"<Christoph.Egger@amd.com>  wrote:
>> 
>>>> What if some other vcpu's nv_n1asid or nv_n2asid got assigned the same HW
>>>> asid in this generation as this vcpu's (now stale, as it's from a previous
>>>> generation's) nv_n2asid? This PCPU can be interleaving execution of other
>>>> HVM VCPUs after all.
>>> 
>>> I am not sure if I got you right. You mean what if two vcpus run on one
>>> physical cpu? In this case svm_do_resume() calls hvm_asid_flush_vcpu()
>>> before so that asid_generation and core_asid_generation do not match and
>>> a new asid is always assigned.
>> 
>> No, it only does that if a given VCPU gets scheduled onto a *different* PCPU
>> than last time it ran.
>> 
>> I've attached a mostly rewritten version of your patch that is about half
>> the size and I believe has a fighting chance of being correct (however it is
>> only build tested). Give it a look and a spin.
> 
> Yes, it is correct. I like the idea to maintain a generation per asid.
> Please apply it. Thanks for this work.

You didn't notice my subtle error in switching n1 and n2 asid selection in
svm_asid_handle_vmrun()? ;-) Actually I bet it would take a lot of testing
to pick up on that error, since the transposition doesn't much matter except
that we are then switched round relative to which ASID gets flushed on
guest-initiated INVLPGA, and also we'd flush the 'wrong' ASID when guest
requests a new L2 guest ASID. Anyway, glad I spotted it before I checked the
patch in! Stale TLB bugs are no fun.

 -- Keir

> Christoph
>