On Thu, Mar 28, 2013 at 5:29 PM, Vasilis Liaskovitis
<vasilis.liaskovi...@profitbricks.com> wrote:
> Hi,
>
> [...]
>>> > >
>>> > > I haven't updated the series for a while, but I can rework if there is 
>>> > > a more
>>> > > clear direction for the community.
>>> > >
>>> > > Another open issue is reference counting of memoryregions in qemu memory
>>> > > model. In order to make memory hot-remove operations safe, we need to 
>>> > > remove
>>> > > a memoryregion after all users (e.g. both guest and block layer) have 
>>> > > stopped
>>> > > using it,
>>> >
>>> > it seems it mostly up to the user who want to hot-(un)plug,
>>> > if user want to un-plug a memory which is kernel's main memory, kernel
>>> > will always run on it(never stop) unless power off.
>>> > and if guest stops, all DIMMs should be safe to hot-remove,
>>> > or else we should do something to let user can unlock all reference.
>>>
>>> it's not only the guest-side that needs to stop using it, we need to make 
>>> sure
>>> that the qemu block layer is also not using the memory region anymore. See 
>>> the 2
>>> links below for discussion:
>>>
>>
>> can't we simply track this(MemoryRegion) usage by ref-count?
>> e.g.
>> every time mr used, inc ref-count, then dec it when unused
>> even for cpu_physical_memory_map and other potential users.
>>
>
> yes, that's the idea the patchset below try to implement, but last
> time I checked this was not upstreamed. I will take a closer look next
> week.
>
The current  problem is that if not all the device convert to support
MemoryRegionOps ref/unref API, the code in address_space_rw will be
ugly.
But I think the virtio data plane will need thread-safe RAM, so can we
just try that for RAM device.
If it is needed, I will update my patches

Regards,
Pingfan
>>> > >  see discussion at
>>> > > http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. 
>>> > > There was a
>>> > > relevant ibm patchset
>>> > > https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html
>>> > > but it was not merged.
>
> - Vasilis

Reply via email to