On Thu, Oct 31, 2024 at 05:27:06PM +0100, Sumanth Korikkar wrote: > On Fri, Oct 25, 2024 at 04:14:45PM +0200, David Hildenbrand wrote: > > Let's finally add s390 support for virtio-mem; my last RFC was sent > > 4 years ago, and a lot changed in the meantime. > > > > The latest QEMU series is available at [1], which contains some more > > details and a usage example on s390 (last patch). > > > > There is not too much in here: The biggest part is querying a new diag(500) > > STORAGE_LIMIT hypercall to obtain the proper "max_physmem_end". > > > > The last three patches are not strictly required but certainly nice-to-have. > > > > Note that -- in contrast to standby memory -- virtio-mem memory must be > > configured to be automatically onlined as soon as hotplugged. The easiest > > approach is using the "memhp_default_state=" kernel parameter or by using > > proper udev rules. More details can be found at [2]. > > > > I have reviving+upstreaming a systemd service to handle configuring > > that on my todo list, but for some reason I keep getting distracted ... > > > > I tested various things, including: > > * Various memory hotplug/hotunplug combinations > > * Device hotplug/hotunplug > > * /proc/iomem output > > * reboot > > * kexec > > * kdump: make sure we properly enter the "kdump mode" in the virtio-mem > > driver > > > > kdump support for virtio-mem memory on s390 will be sent out separately. > > > > v2 -> v3 > > * "s390/kdump: make is_kdump_kernel() consistently return "true" in kdump > > environments only" > > -> Sent out separately [3] > > * "s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM memory > > devices" > > -> No query function for diag500 for now. > > -> Update comment above setup_ident_map_size(). > > -> Optimize/rewrite diag500_storage_limit() [Heiko] > > -> Change handling in detect_physmem_online_ranges [Alexander] > > -> Improve documentation. > > * "s390/sparsemem: provide memory_add_physaddr_to_nid() with CONFIG_NUMA" > > -> Added after testing on systems with CONFIG_NUMA=y > > > > v1 -> v2: > > * Document the new diag500 subfunction > > * Use "s390" instead of "s390x" consistently > > > > [1] https://lkml.kernel.org/r/20241008105455.2302628-1-david@xxxxxxxxxx > > [2] https://virtio-mem.gitlab.io/user-guide/user-guide-linux.html > > [3] https://lkml.kernel.org/r/20241023090651.1115507-1-david@xxxxxxxxxx > > > > Cc: Heiko Carstens <hca@xxxxxxxxxxxxx> > > Cc: Vasily Gorbik <gor@xxxxxxxxxxxxx> > > Cc: Alexander Gordeev <agordeev@xxxxxxxxxxxxx> > > Cc: Christian Borntraeger <borntraeger@xxxxxxxxxxxxx> > > Cc: Sven Schnelle <svens@xxxxxxxxxxxxx> > > Cc: Thomas Huth <thuth@xxxxxxxxxx> > > Cc: Cornelia Huck <cohuck@xxxxxxxxxx> > > Cc: Janosch Frank <frankja@xxxxxxxxxxxxx> > > Cc: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> > > Cc: "Michael S. Tsirkin" <mst@xxxxxxxxxx> > > Cc: Jason Wang <jasowang@xxxxxxxxxx> > > Cc: Xuan Zhuo <xuanzhuo@xxxxxxxxxxxxxxxxx> > > Cc: "Eugenio P?rez" <eperezma@xxxxxxxxxx> > > Cc: Eric Farman <farman@xxxxxxxxxxxxx> > > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > Cc: Jonathan Corbet <corbet@xxxxxxx> > > > > David Hildenbrand (7): > > Documentation: s390-diag.rst: make diag500 a generic KVM hypercall > > Documentation: s390-diag.rst: document diag500(STORAGE LIMIT) > > subfunction > > s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM > > memory devices > > virtio-mem: s390 support > > lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390 > > s390/sparsemem: reduce section size to 128 MiB > > s390/sparsemem: provide memory_add_physaddr_to_nid() with CONFIG_NUMA > > > > Documentation/virt/kvm/s390/s390-diag.rst | 35 +++++++++++++---- > > arch/s390/boot/physmem_info.c | 47 ++++++++++++++++++++++- > > arch/s390/boot/startup.c | 7 +++- > > arch/s390/include/asm/physmem_info.h | 3 ++ > > arch/s390/include/asm/sparsemem.h | 10 ++++- > > drivers/virtio/Kconfig | 12 +++--- > > lib/Kconfig.debug | 2 +- > > 7 files changed, 98 insertions(+), 18 deletions(-) > > > > > > base-commit: ae90f6a6170d7a7a1aa4fddf664fbd093e3023bc > > -- > > 2.46.1 > > > > Tested successfully various memory hotplug operations on lpar. > Just to be more precise, tested memory hotplug/hotunplug combinations + Device hotplug/hotunplug operations on guest. > Tested-by: Sumanth Korikkar <sumanthk@xxxxxxxxxxxxx>
