Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[Vasilis Liaskovitis]

Hi,

On Tue, Mar 19, 2013 at 03:28:38PM +0800, li guang wrote:
[...]
> > > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target 
> > > > is
> > > > supported (both i440fx and q35). There are still several issues, but 
> > > > it's
> > > > been a while since v3 and I wanted to get some more feedback on the 
> > > > current
> > > > state of the patchseries.
> > > >
> > > >
> > > We are working in memory hotplug functionality on pSeries machine. I'm
> > > wondering whether and how we can better integrate things. Do you think the
> > > DIMM abstraction is generic enough to be used in other machine types?
> > 
> > I think the DimmDevice is generic enough but I am open to other 
> > suggestions. 
> > 
> > A related issue is that the patchseries uses a DimmBus to hot-add and 
> > hot-remove
> > DimmDevice. Another approach that has been suggested is to use links<> 
> > between
> > DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc
> > machines respectively). This would be more similar to the CPUState/qom
> > patches - see Andreas Färber's earlier reply to this thread.
> > 
> > I think we should get some consensus from the community/maintainers before 
> > we
> > continue to integrate. 
> > 
> > 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:

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

- Vasilis