On 2012-08-27 15:19, Anthony Liguori wrote: > Liu Ping Fan <qemul...@gmail.com> writes: > >> From: Liu Ping Fan <pingf...@linux.vnet.ibm.com> >> >> Scene: >> obja lies in objA, when objA's ref->0, it will be freed, >> but at that time obja can still be in use. >> >> The real example is: >> typedef struct PCIIDEState { >> PCIDevice dev; >> IDEBus bus[2]; --> create in place >> ..... >> } >> >> When without big lock protection for mmio-dispatch, we will hold >> obj's refcnt. So memory_region_init_io() will replace the third para >> "void *opaque" with "Object *obj". >> With this patch, we can protect PCIIDEState from disappearing during >> mmio-dispatch hold the IDEBus->ref. >> >> And the ref circle has been broken when calling qdev_delete_subtree(). >> >> Signed-off-by: Liu Ping Fan <pingf...@linux.vnet.ibm.com> > > I think this is solving the wrong problem. There are many, many > dependencies a device may have on other devices. Memory allocation > isn't the only one. > > The problem is that we want to make sure that a device doesn't "go away" > while an MMIO dispatch is happening. This is easy to solve without > touching referencing counting. > > The device will hold a lock while the MMIO is being dispatched. The > delete path simply needs to acquire that same lock. This will ensure > that a delete operation cannot finish while MMIO is still in flight.
That's a bit too simple. Quite a few MMIO/PIO fast-paths will work without any device-specific locking, e.g. just to read a simple register value. So we will need reference counting (for devices using private locks), but on the "front-line" object: the memory region. That region will block its owner from disappearing by waiting on dispatch when someone tries to unregister it. Also note that "holding a lock" is easily said but will be more tricky in practice. Quite a significant share of our code will continue to run under BQL, even for devices with their own locks. Init/cleanup functions will likely fall into this category, simply because the surrounding logic is hard to convert into fine-grained locking and is also not performance critical. At the same time, we can't take BQL -> device-lock as we have to support device-lock -> BQL ordering for (slow-path) calls into BQL-protected areas while holding a per-device lock (e.g. device mapping changes). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux