[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion
From: |
liu ping fan |
Subject: |
Re: [Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion |
Date: |
Fri, 10 Aug 2012 14:44:03 +0800 |
On Thu, Aug 9, 2012 at 4:38 PM, Avi Kivity <address@hidden> wrote:
> On 08/09/2012 10:27 AM, liu ping fan wrote:
>> On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity <address@hidden> wrote:
>>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>>> From: Liu Ping Fan <address@hidden>
>>>>
>>>> Using refcnt for mr, so we can separate mr's life cycle management
>>>> from refered object.
>>>> When mr->ref 0->1, inc the refered object.
>>>> When mr->ref 1->0, dec the refered object.
>>>>
>>>> The refered object can be DeviceStae, another mr, or other opaque.
>>>
>>> Please explain the motivation more fully.
>>>
>> Actually, the aim is to mange the reference of an object, used by mem view.
>> DeviceState can be referred by different system, when it comes to the
>> view of subsystem, we hold dev's ref. And any indirect reference will
>> just mr->ref++, not dev's.
>> This can help us avoid the down-walk through the referred chain, like
>> alias----> mr ---> DeviceState.
>
> That is a lot of complexity, for no gain. Manipulating memory regions
> is a slow path, and can be done under the bit qemu lock without any
> complications.
>
OK. I will discard this design.
>>
>> In the previous discussion, you have suggest add dev->ref++ in
>> core_region_add. But I think, if we can move it to higher layer --
>> memory_region_{add,del}_subregion, so we can avoid to duplicate do
>> this in other xx_region_add.
>
> Why would other memory listeners be impacted? They all operate under
> the big qemu lock. If they start using devices outside the lock, then
> they need to take a reference.
>
Yes, if unplug path in the protection of big lock.
And just one extra question, for ram-unplug scene, how do we protect from:
updater: ram-unplug -->qemu free() --> brk() invalidate this vaddr interval
reader: vhost-thread copy data from the interval
I guess something like lock/ref used by them, but can not find such
mechanism in vhost_set_memory() to protect the scene against
vhost_worker()
Thanks and regards,
pingfan
>> As a payment for this, we need to handle alias which can be avoid at
>> core_region_add(). And mr's ref can help to avoid
>> the down-walk.
>
> The payment is two systems of reference counts.
>
> --
> error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be stable when updating, (continued)
[Qemu-devel] [PATCH 05/15] memory: introduce life_ops to MemoryRegion, Liu Ping Fan, 2012/08/08
[Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion, Liu Ping Fan, 2012/08/08
[Qemu-devel] [PATCH 10/15] memory: change tcg related code to using PhysMap, Liu Ping Fan, 2012/08/08
[Qemu-devel] [PATCH 09/15] memory: prepare flatview and radix-tree for rcu style access, Liu Ping Fan, 2012/08/08
Re: [Qemu-devel] [PATCH 09/15] memory: prepare flatview and radix-tree for rcu style access, Blue Swirl, 2012/08/08
[Qemu-devel] [PATCH 13/15] hotplug: introduce qdev_unplug_complete() to remove device from views, Liu Ping Fan, 2012/08/08