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

[Christoph Egger <Christoph.Egger@xxxxxxx>]

On 04/15/11 11:05, Keir Fraser wrote:
> On 15/04/2011 09:20, "Christoph Egger"<Christoph.Egger@xxxxxxx>  wrote:
>
> > On 04/14/11 16:43, Keir Fraser wrote:
> > > On 14/04/2011 15:01, "Christoph Egger"<Christoph.Egger@xxxxxxx>   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()? ;-)
Oh, now that you mention it...

A l2 smp guest actually boots up. Maybe I need to use more vcpus than I 
have physical cpus to hit that bug.
I think, this snippet should be like this:

struct vcpu *curr = current;
struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
struct hvm_vcpu_asid *curr_asid;
bool_t need_flush;
bool_t vcpu_guestmode = 0;

if (nestedhvm_enabled(curr->domain) && nestedhvm_vcpu_in_guestmode(curr))
    vcpu_guestmode = 1;

curr_asid = vcpu_guestmode ?
    &curr->arch.hvm_vcpu.n2_asid : &curr->arch.hvm_vcpu.n1_asid;
need_flush = hvm_asid_handle_vmenter(curr_asid);


Christoph


> 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

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