On 10/23/2012 02:40 PM, Jan Kiszka wrote: > On 2012-10-23 14:28, Avi Kivity wrote: >> On 10/23/2012 02:16 PM, Jan Kiszka wrote: >>> On 2012-10-23 14:12, Paolo Bonzini wrote: >>>> Il 23/10/2012 14:04, Jan Kiszka ha scritto: >>>>>>>>> >>>>>>>>> So the stop_machine idea is thrown away? >>>>>>> >>>>>>> IIRC I convinced myself that it's just as bad. >>>>> One tricky part with stop machine is that legacy code may trigger it >>>>> while holding the BQL, does not expect to lose that lock even for a >>>>> brief while, but synchronizing on other threads does require dropping >>>>> the lock right now. Maybe an implementation detail, but at least a nasty >>>>> one. >>>> >>>> But it would only be triggered by hot-unplug, no? >>> >>> Once all code that adds/removes memory regions from within access >>> handlers is converted. >> >> add/del is fine. memory_region_destroy() is the problem. I have >> patches queued that fix those problems and add an assert() to make sure >> we don't add more. >> >> It's not just memory regions, it's practically anything that can be >> removed and that has callbacks. The two proposals are: >> >> - qomify >> - split unplug into isolate+destroy >> - let the issuer of the callbacks manage the reference counts > > What do you mean with the last one?
Call ref/unref as needed (this patchset). Here, "the issuer of the callbacks" is the memory core. For timer callbacks, it is the timer subsystem. > >> >> vs >> >> - split unplug into isolate+destroy >> - let unplug defer destruction to a bottom half, and stop_machine there >> - if we depend on the results [1], add a continuation >> >> [1] Say a monitor command wants to return only after the block device >> has been detached from qemu > > The monitor is likely harmless (as it's pretty confined). But is that > all? Hunting down all (corner) cases will make switching to this model > tricky. That is my feeling as well. The first model requires more work, but is complete. The second model is easier, but we may run into a wall if we find a case it doesn't cover. -- error compiling committee.c: too many arguments to function
