Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem

[Avi Kivity]

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