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.
--
error compiling committee.c: too many arguments to function
--
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
