[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: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem |
Date: |
Wed, 05 Sep 2012 13:53:23 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 |
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
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, (continued)
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/09/01
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, liu ping fan, 2012/09/03
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, liu ping fan, 2012/09/03
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, liu ping fan, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem,
Avi Kivity <=
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Jan Kiszka, 2012/09/05
- Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/09/05
Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem, Avi Kivity, 2012/09/03