Re: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mardi 04 Avril 2006 10:49, Tian, Kevin a écrit :
> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>
> >Sent: 2006年4月4日 16:39
> >Le Mardi 04 Avril 2006 10:15, Tian, Kevin a écrit :
> >[...]
> >
> >> >diff -r ddc279c91502 xen/arch/ia64/xen/vcpu.c
> >> >--- a/xen/arch/ia64/xen/vcpu.c    Fri Mar 31 21:04:16 2006
> >> >+++ b/xen/arch/ia64/xen/vcpu.c    Mon Apr  3 11:20:57 2006
> >> >+                 do {
> >> >+                         /* Wait until the tlb is not used.  */
> >> >+                         while ((count = PSCBX(vcpu, tlb_inuse)) & 1)
> >> >+                                 cpu_relax ();
> >> >+
> >> >+                         /* Purge tc entries.  */
> >> >+                         vcpu_purge_tr_entry(&PSCBX(vcpu,dtlb));
> >> >+                         vcpu_purge_tr_entry(&PSCBX(vcpu,itlb));
> >>
> >> It's possible tlb_inuse is set again here, however for a new guest tlb
> >> entry which means content of dtlb/itlb may change within this window.
> >
> >Then
> >
> >> the new tlb entry will be incorrectly purged in next loop.
> >
> >The original code unconditionnaly purge tc.  This code does too.  For
> >sure, it
> >is inefficient.
> >Is it incorrect too ?
> >
> >Tristan.
>
> It's an overkill to unconditionally purge dtlb/itlb without check against
> destination range. Guest may still work, since it's only TC. However we'd
> better not do that since it's not syntax of ptc.g.
>
> Your code only based on assumption that domain has single entry
> itlb/dtlb, which doesn't apply to hash vtlb approach. Once Anthony clears
> up the patch which get checked-in, your code doesn't work since you
> need to walk hash vtlb table to compare the destination range that time.
>
> That's why I still prefer to merging vtlb purge together with vhpt purge
> within IPI handler, which saves you from complex thought to handle race
> condition. Anyway, you already have an IPI sent out following vTLB purge.
> Then you can define a vtlb_flush_address within ptc_ga_remote_func,
> with the former defined differently for one entry dtlb/itlb and hash vtlb
> approach.
>
> How do you think?
As Isaku pointed out, vcpu_translate is run with psr.i = 1.  (I think this is 
true).
Therefore an IPI doesn't avoid the race.

BTW, I'd prefer to completly avoid IPI for ptc.ga.  From a few tests, IPI are 
too slow to implement ptc.ga.

Tristan.



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