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

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

On 2012-08-27 19:09, Avi Kivity wrote:
> On 08/27/2012 12:47 AM, Jan Kiszka 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
>> 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
>> 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.
> 
> That's a pretty harsh constraint.

Of course. It's a first step, not a long-term restriction. But we have
to do small steps.

> 
>> 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.
>>
>>
> 
> Deregistration is fine, the problem is destruction.
> 

It isn't as you access memory region states that can change after
deregistration. Devices can remove memory regions from the mapping,
alter and then reinsert them. The last to steps must not happen while
anyone is still using a reference to that region.

Jan

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