All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	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>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>
Subject: Re: [PATCH v1 00/14] s390x: virtio-mem support
Date: Tue, 10 Sep 2024 14:33:40 -0400	[thread overview]
Message-ID: <20240910143224-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240910175809.2135596-1-david@redhat.com>

On Tue, Sep 10, 2024 at 07:57:55PM +0200, David Hildenbrand wrote:
> This series is based on:
>     [PATCH v2] virtio: kconfig: memory devices are PCI only [1]
> 
> I finally found the time (IOW forced myself) to finish virtio-mem
> support on s390x. The last RFC was from 2020, so I won't talk about
> what changed -- a lot changed in the meantime :)
> 
> 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 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)


I don't see anything needing virtio specific here, let me know if
I missed anything.
A quick look is fine so I guess you can add
Acked-by: Michael S. Tsirkin <mst@redhat.com>



> I'll send out the kernel driver bits soon.
> 
> [1] https://lkml.kernel.org/r/20240906101658.514470-1-pbonzini@redhat.com
> [2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
> 
> 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: David Hildenbrand <david@redhat.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>
> 
> 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 memory devices and sparse memory
>     layouts
>   s390x/s390-skeys: prepare for memory devices
>   s390x/pv: check initial, not maximum RAM size
>   s390x/s390-virtio-ccw: prepare for memory devices
>   s390x: introduce s390_get_max_pagesize()
>   s390x/virtio-ccw: add support for virtio based memory devices
>   s390x: virtio-mem support
> 
>  MAINTAINERS                    |   4 +
>  hw/s390x/Kconfig               |   1 +
>  hw/s390x/meson.build           |   4 +-
>  hw/s390x/s390-hypercall.c      |  77 +++++++++++
>  hw/s390x/s390-hypercall.h      |  25 ++++
>  hw/s390x/s390-skeys.c          |   4 +-
>  hw/s390x/s390-stattrib-kvm.c   |  63 +++++----
>  hw/s390x/s390-virtio-ccw.c     | 143 +++++++++++++--------
>  hw/s390x/s390-virtio-hcall.c   |  41 ------
>  hw/s390x/s390-virtio-hcall.h   |  25 ----
>  hw/s390x/sclp.c                |  17 +--
>  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 +-
>  target/s390x/cpu-sysemu.c      |  35 ++++-
>  target/s390x/cpu.h             |   2 +
>  target/s390x/kvm/kvm.c         |  12 +-
>  target/s390x/kvm/pv.c          |   2 +-
>  target/s390x/tcg/misc_helper.c |   6 +-
>  22 files changed, 746 insertions(+), 177 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.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.46.0



  parent reply	other threads:[~2024-09-10 18:34 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 17:57 [PATCH v1 00/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 01/14] s390x/s390-virtio-ccw: don't crash on weird RAM sizes David Hildenbrand
2024-09-11 11:28   ` Janosch Frank
2024-09-11 12:38     ` David Hildenbrand
2024-09-11 12:46       ` Thomas Huth
2024-09-11 12:54         ` David Hildenbrand
2024-09-11 11:58   ` Thomas Huth
2024-09-12 20:28   ` Eric Farman
2024-09-23  9:19   ` David Hildenbrand
2024-09-23 15:36     ` Thomas Huth
2024-09-23 15:39       ` David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 02/14] s390x/s390-virtio-hcall: remove hypercall registration mechanism David Hildenbrand
2024-09-11 16:02   ` Thomas Huth
2024-09-10 17:57 ` [PATCH v1 03/14] s390x/s390-virtio-hcall: prepare for more diag500 hypercalls David Hildenbrand
2024-09-11 17:04   ` Thomas Huth
2024-09-12 13:22   ` Nina Schoetterl-Glausch
2024-09-17 10:45     ` David Hildenbrand
2024-09-17 10:50       ` David Hildenbrand
2024-09-17 11:02         ` David Hildenbrand
2024-09-17 12:59           ` Nina Schoetterl-Glausch
2024-09-10 17:57 ` [PATCH v1 04/14] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2024-09-11 17:05   ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 05/14] s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to machine code David Hildenbrand
2024-09-12  8:07   ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 06/14] s390x: introduce s390_get_memory_limit() David Hildenbrand
2024-09-12  8:10   ` Thomas Huth
2024-09-16 13:20   ` Nina Schoetterl-Glausch
2024-09-17 11:23     ` David Hildenbrand
2024-09-17 12:48       ` Nina Schoetterl-Glausch
2024-09-23  9:20         ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT David Hildenbrand
2024-09-12  8:19   ` Thomas Huth
2024-09-12 10:54     ` Janosch Frank
2024-09-27 18:05     ` Halil Pasic
2024-09-27 18:34       ` David Hildenbrand
2024-09-30 11:11       ` Christian Borntraeger
2024-09-30 12:57         ` Halil Pasic
2024-10-01  9:15           ` Christian Borntraeger
2024-10-01 13:31             ` Halil Pasic
2024-10-01 14:35               ` Christian Borntraeger
2024-09-30 13:13         ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 08/14] s390x/s390-stattrib-kvm: prepare memory devices and sparse memory layouts David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 09/14] s390x/s390-skeys: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 10/14] s390x/pv: check initial, not maximum RAM size David Hildenbrand
2024-09-24 16:22   ` Nina Schoetterl-Glausch
2024-09-24 20:17     ` David Hildenbrand
2024-09-26  9:04       ` David Hildenbrand
2024-09-30 11:15       ` Christian Borntraeger
2024-09-30 11:37         ` Claudio Imbrenda
2024-09-30 13:14           ` David Hildenbrand
2024-09-30 13:26             ` Claudio Imbrenda
2024-09-10 17:58 ` [PATCH v1 11/14] s390x/s390-virtio-ccw: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 12/14] s390x: introduce s390_get_max_pagesize() David Hildenbrand
2024-09-26 10:22   ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 13/14] s390x/virtio-ccw: add support for virtio based memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 14/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 18:33 ` Michael S. Tsirkin [this message]
2024-09-10 18:45   ` [PATCH v1 00/14] " David Hildenbrand
2024-09-11 11:49 ` Janosch Frank
2024-09-11 12:28   ` David Hildenbrand
2024-09-11 14:04     ` Michael S. Tsirkin
2024-09-11 15:38       ` Cornelia Huck
2024-09-11 19:09         ` David Hildenbrand
2024-09-27 18:20           ` Halil Pasic
2024-09-27 18:29             ` David Hildenbrand
2024-09-30 21:49               ` Halil Pasic
2024-10-01  8:54                 ` David Hildenbrand
2024-10-02  9:04                   ` Janosch Frank
2024-10-07 12:23                     ` 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=20240910143224-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@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.