RE: [Xen-devel] [PATCH] VMX: avoid taking locks with irqs disabled

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Tuesday, October 21, 2008 8:37 PM
>On 21/10/08 13:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>> Actually this new partitioning of locks into two
>equivalence classes is
>>> begging for some run-time checking in debug builds. I'll sort
>>> out a patch
>>> for that.
>>
>> Did you flush out the patch into xen bits? I guess there may
>> be other instances breaking that guideline. Just curious whether
>> Linux side already recognized similar constraints. It's possibly
>> not. Then another angle is, instead of pushing constraint on
>> spinlock usage, could we instead change timer rendezvous
>> style? Use softirq instead of call function should release the
>> constraints like stop_machine. :-)
>
>I'm flushing out fixes for this class of race before I check
>in the debug
>code. I don't think it's an unreasonable new constraint, it
>just hasn't been
>enforced before and so various Xen code breaks. I should get
>the patches
>flushed out later today.

I'm a bit curious why call funtion ipi is required here, or why
rendezvous is required here. All the rendezvous stuff in current
ipi function is just:
a) cpu0 waits for all other cpus entering rendezvous loop, and
then update master_stime
b) other cpus enter loop and wait for cpu0 to update master_stime

Then each cpu continues with rest stuff independently. In this
case, it seems enough to just ensure master_stime updated
before sending softirq, and thus ipi is actually not required.
Do I miss anything? :-)

Thanks,
Kevin

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