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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).