[SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
vasilis.liaskovitis at profitbricks.com
Tue Mar 26 17:43:47 CET 2013
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.
More information about the SeaBIOS