On 09/05/2012 01:36 PM, Jan Kiszka wrote: >> >> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a >> corresponding unref), which has the following requirements: >> >> - if the refcount is nonzero, MemoryRegion::opaque is safe to use >> - if the refcount is nonzero, the MemoryRegion itself is stable. > > The second point means that the memory subsystem will cache the region > state and apply changes only after leaving a handler that performed them?
No. I/O callbacks may be called after a region has been disabled. I guess we can restrict this to converted regions, so we don't introduce regressions. >> As outlined above, I now prefer MemoryRegionOps::ref/unref. >> >> Advantages compared to MemoryRegionOps::object(): >> - decoupled from the QOM framework >> >> Disadvantages: >> - more boilerplate code in converted devices >> >> Since we are likely to convert few devices to lockless dispatch, I >> believe the tradeoff is justified. But let's hear Jan and the others. > > I still need to dig into related posts of the past days, lost track, but > the above sounds much better. > > Besides the question of what to protect and how, one important thing > IMHO is that we are able to switch locking behaviour on a per region > basis. And that should also be feasible this way. It was also possible with MemoryRegionOps::object() - no one said all regions for a device have to refer to the same object (and there is a difference between locking and reference counting, each callback could take a different lock). But it is more natural with MemoryRegionOps::ref(). -- error compiling committee.c: too many arguments to function
