Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps

[Jan Kiszka <jan.kiszka@siemens.com>]

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?

> 
> 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.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux