qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem
Date: Mon, 27 Aug 2012 10:09:16 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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.

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

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]