Re: [PATCH 06/15] memory: use refcnt to manage MemoryRegion

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

 



On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan <pingfank@xxxxxxxxxxxxxxxxxx>
>>
>> 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.

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

Regards,
pingfan
> Usually a MemoryRegion will be embedded within some DeviceState, or its
> lifecycle will be managed by the DeviceState.  So long as we keep the
> DeviceState alive all associated MemoryRegions should be alive as well.
>  Why not do this directly?
>
>
> --
> error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux