On Mon, Aug 27, 2012 at 3:47 PM, Jan Kiszka <jan.kis...@web.de> wrote: > On 2012-08-27 09:01, Paolo Bonzini wrote: >> Il 25/08/2012 09:42, liu ping fan ha scritto: >>>>> >>>>> I don't see why MMIO dispatch should hold the IDEBus ref rather than the >>>>> PCIIDEState. >>>>> >>> When transfer memory_region_init_io() 3rd para from void* opaque to >>> Object* obj, the obj : opaque is not neccessary 1:1 map. For such >>> situation, in order to let MemoryRegionOps tell between them, we >>> should pass PCIIDEState->bus[0], bus[1] separately. >> >> The rule should be that the obj is the object that you want referenced, >> and that should be the PCIIDEState. >> >> But this is anyway moot because it only applies to objects that are >> converted to use unlocked dispatch. This likely will not be the case >> for IDE. > > BTW, I'm pretty sure - after implementing the basics for BQL-free PIO > dispatching - that device objects are the wrong target for reference
Hi Jan, thanks for reminder, but could you explain it more detail? mmio dispatch table holds 1 ref for device, before releasing this ref,( When unplugging, we detach all the device's mr from memory, then drop the ref. So I think that no leak will be exposed by mr and it is safe to use device as target for reference. > counting. We keep memory regions in our dispatching tables (PIO > dispatching needs some refactoring for this), and those regions need > protection for BQL-free use. Devices can't pass away as long as the have Yes, it is right. Device can pass away only after mr removed from dispatching tables Thanx pingfan > referenced regions, memory region deregistration services will have to > take care of this. > > I'm currently not using reference counting at all, I'm enforcing that > only BQL-protected regions can be deregistered. > > Also note that there seems to be another misconception in the > discussions: deregistration is not only bound to device unplug. It also > happens on device reconfiguration, e.g. PCI BAR (re-)mapping. Another > strong indicator that we should worry about individual memory regions, > not devices. > > Jan > >
