From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>,
Janosch Frank <frankja@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
David Hildenbrand <david@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>,
Richard Henderson <rth@twiddle.net>
Subject: [PATCH RFCv3 0/9] s390x: initial support for virtio-mem
Date: Fri, 24 Jul 2020 16:37:41 +0200 [thread overview]
Message-ID: <20200724143750.59836-1-david@redhat.com> (raw)
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
next reply other threads:[~2020-07-24 14:40 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 14:37 David Hildenbrand [this message]
2020-07-24 14:37 ` [PATCH RFCv3 1/9] s390x: move setting of maximum ram size to machine init David Hildenbrand
2020-07-27 9:13 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 2/9] s390x/diag: no need to check for PGM_PRIVILEGED in diag308 David Hildenbrand
2020-07-27 9:14 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 3/9] s390x: remove hypercall registration mechanism David Hildenbrand
2020-07-27 9:24 ` Cornelia Huck
2020-07-27 9:29 ` David Hildenbrand
2020-07-27 9:48 ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 4/9] s390x: prepare for more diag500 hypercalls David Hildenbrand
2020-07-27 9:42 ` Cornelia Huck
2020-07-27 10:45 ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 5/9] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region David Hildenbrand
2020-07-27 9:48 ` Cornelia Huck
2020-07-27 9:52 ` David Hildenbrand
2020-07-27 10:09 ` Cornelia Huck
2020-07-27 10:12 ` David Hildenbrand
2020-07-27 11:15 ` Heiko Carstens
2020-07-27 12:02 ` David Hildenbrand
2020-07-28 7:10 ` Cornelia Huck
2020-07-29 8:57 ` David Hildenbrand
2020-07-29 9:37 ` Cornelia Huck
2020-07-29 9:57 ` David Hildenbrand
2020-07-29 10:13 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 7/9] s390x: prepare device memory address space David Hildenbrand
2020-07-27 9:56 ` Cornelia Huck
2020-07-27 9:57 ` David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 8/9] s390x: implement virtio-mem-ccw David Hildenbrand
2020-07-27 9:58 ` Cornelia Huck
2020-07-27 10:02 ` David Hildenbrand
2020-07-27 10:11 ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 9/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-27 10:03 ` Cornelia Huck
2020-07-27 10:04 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200724143750.59836-1-david@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.