Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
On Fri, Jan 11, 2013 at 2:57 AM, Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com wrote: IIRC q35 supports memory hotplug natively (picked up in some discussion). Is that correct? From previous discussion I also understand that q35 supports native hotplug. Sections 5.1 and 5.2 of the spec describe the MCH registers but the native memory hotplug specifics are not yet clear to me. Any pointers from the spec are welcome. Ping. Could anyone who's familiar with the q35 spec provide some pointers on native memory hotplug details in the spec? I see pcie hotplug registers but can't find memory hotplug interface details. If I am not mistaken, the spec is here: http://www.intel.com/design/chipsets/datashts/316966.htm Is the q35 memory hotplug support supposed to be an shpc-like interface geared towards memory slots instead of pci slots? I think there is no dedicated pci express downstream port for memory slots, so native plug is not available. thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
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. 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
在 2013-03-26二的 11:20 -0300，Eduardo Habkost写道： On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote: 在 2013-01-09三的 01:08 +0100，Andreas Färber写道： Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of linkSocket properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of linkDIMMs on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) Sorry, what's link, did it adopted by cpu-QOM? link... is a QOM construct, allowing properties that point to other objects. We don't use it on the CPU objects yet. can you give some hints? Look for mentions of link in the doc comments at include/qom/object.h. OK, I see, Thanks! ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote: 在 2013-01-09三的 01:08 +0100，Andreas Färber写道： Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of linkSocket properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of linkDIMMs on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) Sorry, what's link, did it adopted by cpu-QOM? link... is a QOM construct, allowing properties that point to other objects. We don't use it on the CPU objects yet. can you give some hints? Look for mentions of link in the doc comments at include/qom/object.h. -- Eduardo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
On Tue, 18 Dec 2012 13:41:28 +0100 Vasilis Liaskovitis vasilis.liaskovi...@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. It seems this series doesn't apply anymore, do you plan to respin it? Also, some months ago I saw patches flying on linux-mm fixing some issues related to memory hotplug, so should this work with latest Linux kernel? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Hi, On Tue, Mar 19, 2013 at 02:30:25PM +0800, li guang wrote: 在 2013-01-10四的 19:57 +0100，Vasilis Liaskovitis写道： IIRC q35 supports memory hotplug natively (picked up in some discussion). Is that correct? From previous discussion I also understand that q35 supports native hotplug. Sections 5.1 and 5.2 of the spec describe the MCH registers but the native memory hotplug specifics are not yet clear to me. Any pointers from the spec are welcome. Ping. Could anyone who's familiar with the q35 spec provide some pointers on native memory hotplug details in the spec? I see pcie hotplug registers but can't find memory hotplug interface details. If I am not mistaken, the spec is here: http://www.intel.com/design/chipsets/datashts/316966.htm Is the q35 memory hotplug support supposed to be an shpc-like interface geared towards memory slots instead of pci slots? seems there's no so-called q35-native support that was also my first impression when scanning the specification. Wasn't native memory hotplug capabilities one of the reasons that q35 got picked as the next pc chipset? thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Hi, On Tue, Mar 26, 2013 at 10:47:01AM -0400, Luiz Capitulino wrote: On Tue, 18 Dec 2012 13:41:28 +0100 Vasilis Liaskovitis vasilis.liaskovi...@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. It seems this series doesn't apply anymore, do you plan to respin it? I 'll respin sometime in April due to other work currently. Also, some months ago I saw patches flying on linux-mm fixing some issues related to memory hotplug, so should this work with latest Linux kernel? hot-add is working. But hot-remove is broken in mainline and still in progress. See discussion at: https://lkml.org/lkml/2013/3/25/490 thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
在 2013-03-26二的 17:58 +0100，Vasilis Liaskovitis写道： Hi, On Tue, Mar 19, 2013 at 02:30:25PM +0800, li guang wrote: 在 2013-01-10四的 19:57 +0100，Vasilis Liaskovitis写道： IIRC q35 supports memory hotplug natively (picked up in some discussion). Is that correct? From previous discussion I also understand that q35 supports native hotplug. Sections 5.1 and 5.2 of the spec describe the MCH registers but the native memory hotplug specifics are not yet clear to me. Any pointers from the spec are welcome. Ping. Could anyone who's familiar with the q35 spec provide some pointers on native memory hotplug details in the spec? I see pcie hotplug registers but can't find memory hotplug interface details. If I am not mistaken, the spec is here: http://www.intel.com/design/chipsets/datashts/316966.htm Is the q35 memory hotplug support supposed to be an shpc-like interface geared towards memory slots instead of pci slots? seems there's no so-called q35-native support that was also my first impression when scanning the specification. Wasn't native memory hotplug capabilities one of the reasons that q35 got picked as the next pc chipset? Um, I can't find the original statement of q35, but I think if we can't find in intel's official SPEC, then we have to say 'there's no q35-native support'. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
在 2013-01-09三的 01:08 +0100，Andreas Färber写道： Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of linkSocket properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of linkDIMMs on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) Sorry, what's link, did it adopted by cpu-QOM? can you give some hints? Thanks! ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
在 2013-01-10四的 19:57 +0100，Vasilis Liaskovitis写道： IIRC q35 supports memory hotplug natively (picked up in some discussion). Is that correct? From previous discussion I also understand that q35 supports native hotplug. Sections 5.1 and 5.2 of the spec describe the MCH registers but the native memory hotplug specifics are not yet clear to me. Any pointers from the spec are welcome. Ping. Could anyone who's familiar with the q35 spec provide some pointers on native memory hotplug details in the spec? I see pcie hotplug registers but can't find memory hotplug interface details. If I am not mistaken, the spec is here: http://www.intel.com/design/chipsets/datashts/316966.htm Is the q35 memory hotplug support supposed to be an shpc-like interface geared towards memory slots instead of pci slots? seems there's no so-called q35-native support ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
在 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.liaskovi...@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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
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.liaskovi...@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, 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis vasilis.liaskovi...@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? 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 starting physical address for all dimms is calculated from top of memory, during memory controller init, skipping the pci hole at [PCI_HOLE_START, 4G). e.g. -device dimm,id=dimm0,size=512M,node=0,populated=off,bus=membus.0 will define a 512M memory dimm belonging to numa node 0, on bus membus.0. Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 Changes v3-v4 - Dimms added with normal -device argument (extra -dimm arg dropped). - multiple memory buses can be registered. Memory buses of the real hw/chipset or a paravirtual memory bus can be added. - acpi implementation uses memory API instead of old ioports. - Support for q35/ich9 added (still buggy, see patch 12/31). - piix4/i440fx initialization code has been refactored to resemble q35. This will allow memory map initialization at chipset qdev init time for both machines, as well as more similar code. - Hot-remove functionality has been moved to separate patches. Hot-remove no longer frees memory but unmaps the dimm/qdev device from the guest's view. Freeing the memory should happen when the last user unrefs/unmaps the memory, see also (work in progress): https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg00728.html https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html - new qmp/hmp command for the state of each dimm (on/off) Changes v2-v3 - qdev integration. Dimms are attached to a dimmbus. The dimmbus is a child of i440fx device in the pc machine. Hot-add and remove are done with normal device_add / device_del operations on the dimmbus. New commands dimm_add and dimm_del are obsolete. - Add _PS3 method to allow OSPM-induced hot operations. - pci-window calculation in Seabios takes dimms into account(for both 32-bit and 64-bit windows) - rename new qmp commands: query-memory-total and query-memory-hotplug - balloon driver can see the hotplugged memory Changes v1-v2 - memory map is automatically calculated for hotplug dimms. Dimms are added from top-of-memory skipping the pci hole at [PCI_HOLE_START, 4G). - Renamed from -memslot to -dimm. Commands changed to dimm_add, dimm_del - Seabios ejection array reduced to a byte. Use extraction macros for dimm ssdt. - additional SRAT paravirt info does not break previous SRAT fw_cfg layout. - Documentation of new acpi_piix4 registers and paravirt data. - add ACPI _OST support for _OST enabled guests. This allows qemu to receive notification for success / failure of memory hot-add and hot-remove operations. Guest needs to support _OST (https://lkml.org/lkml/2012/6/25/321) - add monitor info command to report total guest memory (initial + hot-added) Issues: - hot-remove needs to only unmap the dimm device from guest's view. Freeing the memory should happen when the last user of the device (e.g. virtio-blk) unrefs the device. A testcase is needed for this. - Live Migration: Ramblocks are migrated before qdev VMStates are migrated. So the DimmDevice is handled diferrently than other devices. Should this be reworked ?( DimmDevice structure currently does not define a VMStateDescription) Live migration works as long as the dimm layout (command line args) are identical at the source and destination qemu command line, and destination takes into account hot-operations that have occured on source. (v3 patch 10/19 created the DimmDevice that corresponds to an unknown incoming ramblock, e.g. for a dimm that was hot-added on source. but has been dropped for the moment). - A main blocker issue is windows guest functionality. The patchset does not work for windows currently. Testing on win2012 server RC or windows2008 consumer prerelease, when adding a DIMM, there is a BSOD with ACPI_BIOS_ERROR
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Hi, On Wed, Jan 09, 2013 at 01:08:52AM +0100, Andreas Färber wrote: Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Due to the fixed layout requirement, all memory devices need to be specified at the command line. This was done with a separate -dimm argument in previous versions (see v3), but some reviewers didn't like the extra argument and suggested handling everything with the normal -device arg. So -device dimm,... saves the layout for *all* memory devices. However for populated=off dimms, the device is actually *not* created at startup. This is why the following combination is not contradictory: Dimm descirption at startup: -device dimm,id=mydimm0,bus=membus.0,size=1G,node=0,populated=off Hot-add with monitor command: device_add dimm,id=mydimm0,bus=membus.0 If on the other hand we specify: -device dimm,id=mydimm0,bus=membus.0,size=1G,node=0,populated=on the dimm device is indeed created at startup. granted it's confusing, but this is how v4 handles the fixed layout/device creation without adding a new command line argument for the layout. Better solutions are welcome. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of linkSocket properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of linkDIMMs on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) This may work for a fixed number of PV dimms. On the other hand some other reviewers like the idea of modelling the memory bus (DimmBus), either for paravirtualized features (e.g. i440fx) or for emulated memory controllers in the future. I assume we either go with a bus or links, and not both. Btw, is the CPU linksocket feature already implemented in a qom-cpu branch? I haven't tested qom-cpu for a long time, but I could take a look as a point of reference. thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Am 10.01.2013 18:36, schrieb Vasilis Liaskovitis: Btw, is the CPU linksocket feature already implemented in a qom-cpu branch? No, the latest topology series moves fields around as preparation. There's still one CPUState per hyperthread, but as a DeviceState now. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of linkSocket properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of linkDIMMs on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
