Avi Kivity wrote: > On 02/18/2010 11:45 AM, 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. > > One way out would be to have a KVM_REQ_IN_PROGRESS, set it in > make_request, clear it in the IPI function. > > If a second make_request sees it already set, it can simply busy wait > until it is cleared, without sending the IPI. Of course the busy wait > means we can't enable preemption (or we may busy wait on an unscheduled > task), but at least the requests can proceed in parallel instead of > serializing. ...or include VCPUs with KVM_REQ_IN_PROGRESS set into the IPI set even if they already have the desired request bit set. Then we should serialize in smp_call_function_many. 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
