Avi Kivity wrote: > On 02/18/2010 11:40 AM, Jan Kiszka wrote: >>> Meanwhile, if anyone has any idea how to kill this lock, I'd love to see it. >>> >>> >> What concurrency does it resolve in the end? On first glance, it only >> synchronize the fiddling with pre-VCPU request bits, right? What forces >> us to do this? Wouldn't it suffice to disable preemption (thus >> migration) and the let concurrent requests race for setting the bits? I >> mean if some request bit was already set on entry, we don't include the >> related VCPU in smp_call_function_many anyway. >> > > It's more difficult. > > vcpu 0: sets request bit on vcpu 2 > vcpu 1: test_and_set request bit on vcpu 2, returns already set > vcpu 1: returns > vcpu 0: sends IPI > vcpu 0: returns > > so vcpu 1 returns before the IPI was performed. If the request was a > tlb flush, for example, vcpu 1 may free a page that is still in vcpu 2's > tlb. So the requests bits we are interested in are exclusively set in this function under requests_lock? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
