[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

BTW, I just meant for time rendezvous code, not for what you're
adding to spinlock which seems safer to avoid similar dead lock
when real rendezvous usage is introduced in future.


>From: Tian, Kevin
>Sent: Tuesday, October 21, 2008 8:50 PM
>>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? :-)
>Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.