[PATCH RFCv3 0/9] s390x: initial support for virtio-mem

[David Hildenbrand]

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:
    git@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:
    git@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