在 2013-02-28四的 11:18 +0100，Vasilis Liaskovitis写道：
Hi,
sorry for the delay. On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote:
On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis < vasilis.liaskovitis@profitbricks.com> 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.
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.
Overview:
Dimm device layout is modeled with a normal qemu device:
"-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0"
How does this will handle the no-hotplugable memory for example the memory passed in '-m' parameter?
The non-hotpluggable initial memory (-m) is currently not modelled at all as a DimmDevice. We may want to model it though.
thanks,
- Vasilis
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
-
li guang -
Vasilis Liaskovitis