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
