All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: "David Hildenbrand" <david@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Eric Farman" <farman@linux.ibm.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Nina Schoetterl-Glausch" <nsg@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: [PATCH v3 00/14] s390x: virtio-mem support
Date: Thu, 19 Dec 2024 15:41:01 +0100	[thread overview]
Message-ID: <20241219144115.2820241-1-david@redhat.com> (raw)

Resending it with minor make-weird-things-compile fixes. Will queue this
shortly again + resend the PULL request if there are no comments. Based on
current master.

There is really not much left to do on s390x, because virtio-mem already
implements most things we need today (e.g., early-migration,
unplugged-inaccessible). The biggest part of this series is just doing what
we do with virtio-pci, wiring it up in the machine hotplug handler and ...
well, messing with the physical memory layout where we can now exceed
initial RAM size and have sparsity (memory holes).

I tested a lot of things, including:
 * Memory hotplug/unplug
 * Device hotplug/unplug
 * System resets / reboots
 * Migrate to/from file (including storage attributes under KVM)
 * Basic live migration
 * Basic postcopy live migration

More details on how to use it on s390x -- which is pretty much how
we use it on other architectures, except
s/virtio-mem-pci/virtio-mem-ccw/ --- is in the last patch.

This series introduces a new diag(500) "STORAGE LIMIT" subcode that will
be documented in the kernel and at [2] once this+kernel part go upstream.

There are not many s390x-specific virtio-mem future work items, except:
* Storage attribute migration might be improved
* We might want to reset storage attributes of unplugged memory
  (might or might not be required for upcoming page table reclaim in
   Linux; TBD)

The Linux driver has been merged into 6.13-rc1.

[1] https://lkml.kernel.org/r/20240906101658.514470-1-pbonzini@redhat.com
[2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec

v2 -> v3:
- "s390x/s390-virtio-hcall: remove hypercall registration mechanism"
 -> Move s390-virtio-hcall.c under CONFIG_S390_CCW_VIRTIO and use
    ugly-but-necessary CONFIG_S390_CCW_VIRTIO in target/ code to
    make it compile with weird configs without CONFIG_S390_CCW_VIRTIO.
    (I don't think we want to use stubs, most of that code does not make
     sense to compile without CONFIG_S390_CCW_VIRTIO; but that will have to
     be a separate cleanup)
- "s390x: introduce s390_get_memory_limit()"
 -> Inline s390_get_memory_limit() for the same reason
 -> Initialize hw_limit to 0 to make some compilers happy
- Adjust other patches to these changes

v1 -> v2:
* "s390x/s390-virtio-hcall: prepare for more diag500 hypercalls"
 - Turn handle_diag_500() into a void function
 - Inject PGM_SPECIFICATION from handle_diag_500() directly
* "s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to
   machine code"
 - Move code to a new function to make further changes easier
 - Adjust s390_pv_vm_try_disable_async() to stay in sync with the
   maxram->ram change
* "s390x: introduce s390_get_memory_limit()"
 - Store limit in machine
 - Move s390_set_memory_limit() from target code into machine code
* "s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT"
 - Move handling into a separate function now that we lookup the machine
* "s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory
   layouts"
 - Adjust to s390_get_memory_limit() changes
* "s390x/s390-skeys: prepare for memory devices"
 - Adjust to s390_get_memory_limit() changes
* "s390x/pv: prepare for memory devices"
 - Use s390_get_memory_limit()
* "s390x: remember the maximum page size"
 - Store it in the machine
 - Move s390_set_max_pagesize() from target code into machine code
 - No need for s390_get_max_pagesize()
* "s390x/virtio-ccw: add support for virtio based memory devices"
 - Move machine wire-up code from virtio-mem patch into this patch
 - Add stubs to make compilation without virtio-mem work
* "s390x: virtio-mem support"
 - Move machine write-up code to previous patch

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Eric Farman <farman@linux.ibm.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>

David Hildenbrand (14):
  s390x/s390-virtio-ccw: don't crash on weird RAM sizes
  s390x/s390-virtio-hcall: remove hypercall registration mechanism
  s390x/s390-virtio-hcall: prepare for more diag500 hypercalls
  s390x: rename s390-virtio-hcall* to s390-hypercall*
  s390x/s390-virtio-ccw: move setting the maximum guest size from sclp
    to machine code
  s390x: introduce s390_get_memory_limit()
  s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT
  s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory
    layouts
  s390x/s390-skeys: prepare for memory devices
  s390x/s390-virtio-ccw: prepare for memory devices
  s390x/pv: prepare for memory devices
  s390x: remember the maximum page size
  s390x/virtio-ccw: add support for virtio based memory devices
  s390x: virtio-mem support

 MAINTAINERS                        |   5 +
 hw/s390x/Kconfig                   |   1 +
 hw/s390x/meson.build               |  10 +-
 hw/s390x/s390-hypercall.c          |  85 +++++++++++
 hw/s390x/s390-hypercall.h          |  25 ++++
 hw/s390x/s390-skeys.c              |   6 +-
 hw/s390x/s390-stattrib-kvm.c       |  67 ++++++---
 hw/s390x/s390-virtio-ccw.c         | 160 +++++++++++++-------
 hw/s390x/s390-virtio-hcall.c       |  41 ------
 hw/s390x/s390-virtio-hcall.h       |  25 ----
 hw/s390x/sclp.c                    |  17 +--
 hw/s390x/virtio-ccw-md-stubs.c     |  24 +++
 hw/s390x/virtio-ccw-md.c           | 153 +++++++++++++++++++
 hw/s390x/virtio-ccw-md.h           |  44 ++++++
 hw/s390x/virtio-ccw-mem.c          | 226 +++++++++++++++++++++++++++++
 hw/s390x/virtio-ccw-mem.h          |  34 +++++
 hw/virtio/Kconfig                  |   1 +
 hw/virtio/virtio-mem.c             |   4 +-
 include/hw/s390x/s390-virtio-ccw.h |   9 ++
 target/s390x/cpu-sysemu.c          |  15 --
 target/s390x/cpu.h                 |   2 -
 target/s390x/kvm/kvm.c             |  21 +--
 target/s390x/kvm/pv.c              |   2 +-
 target/s390x/tcg/misc_helper.c     |  10 +-
 24 files changed, 790 insertions(+), 197 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-md-stubs.c
 create mode 100644 hw/s390x/virtio-ccw-md.c
 create mode 100644 hw/s390x/virtio-ccw-md.h
 create mode 100644 hw/s390x/virtio-ccw-mem.c
 create mode 100644 hw/s390x/virtio-ccw-mem.h

-- 
2.47.1



             reply	other threads:[~2024-12-19 16:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 14:41 David Hildenbrand [this message]
2024-12-19 14:41 ` [PATCH v3 01/14] s390x/s390-virtio-ccw: don't crash on weird RAM sizes David Hildenbrand
2024-12-24 12:32   ` Michael Tokarev
2024-12-24 12:40     ` David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 02/14] s390x/s390-virtio-hcall: remove hypercall registration mechanism David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 03/14] s390x/s390-virtio-hcall: prepare for more diag500 hypercalls David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 04/14] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 05/14] s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to machine code David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 06/14] s390x: introduce s390_get_memory_limit() David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 08/14] s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 09/14] s390x/s390-skeys: prepare for memory devices David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 10/14] s390x/s390-virtio-ccw: " David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 11/14] s390x/pv: " David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 12/14] s390x: remember the maximum page size David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 13/14] s390x/virtio-ccw: add support for virtio based memory devices David Hildenbrand
2024-12-19 14:41 ` [PATCH v3 14/14] s390x: virtio-mem support 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=20241219144115.2820241-1-david@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=nsg@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --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.