[Top][All Lists]
[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: |
liu ping fan |
Subject: |
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem |
Date: |
Mon, 27 Aug 2012 16:17:32 +0800 |
On Mon, Aug 27, 2012 at 3:47 PM, Jan Kiszka <address@hidden> 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
Hi Jan, thanks for reminder, but could you explain it more detail?
mmio dispatch table holds 1 ref for device, before releasing this
ref,( When unplugging, we detach all the device's mr from memory, then
drop the ref. So I think that no leak will be exposed by mr and it is
safe to use device as 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
Yes, it is right. Device can pass away only after mr removed from
dispatching tables
Thanx pingfan
> 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.
>
> 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.
>
> Jan
>
>
- Re: [Qemu-devel] [PATCH 06/10] qom: expose object_property_del_child, (continued)
- [Qemu-devel] [PATCH 07/10] unplug: using new intf qdev_delete_subtree in acpi_piix_eject_slot, Liu Ping Fan, 2012/08/24
- [Qemu-devel] [PATCH 09/10] mon: release dev's ref hold by qdev_get_peripheral, Liu Ping Fan, 2012/08/24
- [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Liu Ping Fan, 2012/08/24
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Paolo Bonzini, 2012/08/24
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/08/27
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/08/27