This wires up the initial, basic version of virito-mem for s390x. General information about virtio-mem can be found at [1] and in QEMU commit [2]. Patch #5 contains a short example for s390x.
virtio-mem for x86-64 Linux is part of v5.8-rc1. A branch with a s390x prototype can be found at: g...@github.com:davidhildenbrand/linux.git virtio-mem-s390x Note that the kernel should either be compiled via CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE, or "memhp_default_state=online" should be passed on the kernel cmdline. This series can be found at: g...@github.com:davidhildenbrand/qemu.git virtio-mem-s390x-rfcv3 Related to s390x, we'll have to tackle migration of storage keys and storage attributes (especially, maybe skipping unplugged parts). Not sure if I am missing something else (any ideas?). For virtio-mem in general, there are a couple of TODOs, e.g., documented in [1] and [2], both in QEMU and Linux. However, the basics are around. I only tested this with fairly small amount of RAM in a z/VM environemnt and under TCG ... [1] https://virtio-mem.gitlab.io/ [2] 910b25766b33 ("virtio-mem: Paravirtualized memory hot(un)plug") RFCv2 -> RFCv3: - Use a new diag500 subcode to communicate the memory device region. Don't use diag260. Clarify why device memory is never exposed via other HW/firmware interface. (thanks Heiko for the discussion and looking into this!). This needed kernel changes (updated the Linux kernel branch) - Added -- "s390x: remove hypercall registration mechanism" -- "s390x: prepare for more diag500 hypercalls" -- "s390x: rename s390-virtio-hcall* to s390-hypercall*" -- "s390x/diag500: subcode to query device memory region" - "s390x: initial support for virtio-mem" -- Also wire-up virtio-mem-pci, although it does not seem to be compatible (yet?) due to MSI-X RFCv1 -> RFCv2: - "s390x/diag: no need to check for PGM_PRIVILEGED in diag308" -- Added - "s390x/diag: implement diag260" -- Implement according to doc (fix error cases) -- Implement subcode 0xc. -- Enable the new diag unconditionally - "s390x: prepare device memory address space" -- Expose maxram size now via diag260 (0xc), not via SCLP. Unfmodified guests can now boot without any issues. This needed kernel changes (updated the Linux kernel branch) - "s390x: implement virtio-mem-ccw" -- Force virtio revision 1 David Hildenbrand (9): s390x: move setting of maximum ram size to machine init s390x/diag: no need to check for PGM_PRIVILEGED in diag308 s390x: remove hypercall registration mechanism s390x: prepare for more diag500 hypercalls s390x: rename s390-virtio-hcall* to s390-hypercall* s390x/diag: subcode to query device memory region s390x: prepare device memory address space s390x: implement virtio-mem-ccw s390x: initial support for virtio-mem hw/s390x/Kconfig | 1 + hw/s390x/Makefile.objs | 3 +- hw/s390x/s390-hypercall.c | 79 +++++++++++ hw/s390x/s390-hypercall.h | 22 +++ hw/s390x/s390-virtio-ccw.c | 207 +++++++++++++++++++++++------ hw/s390x/s390-virtio-hcall.c | 41 ------ hw/s390x/s390-virtio-hcall.h | 23 ---- hw/s390x/sclp.c | 21 +-- hw/s390x/virtio-ccw-mem.c | 167 +++++++++++++++++++++++ hw/s390x/virtio-ccw.h | 13 ++ hw/virtio/virtio-mem.c | 2 + include/hw/s390x/s390-virtio-ccw.h | 3 + target/s390x/diag.c | 5 - target/s390x/kvm.c | 17 +-- target/s390x/misc_helper.c | 5 +- 15 files changed, 466 insertions(+), 143 deletions(-) create mode 100644 hw/s390x/s390-hypercall.c create mode 100644 hw/s390x/s390-hypercall.h delete mode 100644 hw/s390x/s390-virtio-hcall.c delete mode 100644 hw/s390x/s390-virtio-hcall.h create mode 100644 hw/s390x/virtio-ccw-mem.c -- 2.26.2