On Wed, May 20, 2009 at 05:29:23PM +0300, Avi Kivity wrote: > Marcelo Tosatti wrote: > > > >>> So we have a function that takes a lock and conditionally releases it? >>> >> >> Yes, but it is correct: it will only return with the lock held in case >> it returns 1, in which case its guaranteed ->write will be called (which >> will unlock it). >> >> It should check the range first and/or use some smarter synchronization, >> but one thing at a time. >> > > Yes it's correct but we'll get an endless stream of patches to 'fix' it > because it is so unorthodox. Does it have to guarantee any kind of ordering in case of parallel writes by distincting vcpus? This is what it does now (so if a vcpu arrives first, the second will wait until the first is finished processing). I suppose that is the responsability of the guest (if it does MMIO writes to a device in parallel it'll screwup in real HW too). Because in such case, you can drop the mutex and protect only the kvm data. -- 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
