From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: 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>,
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>
Subject: Re: [PATCH v2 00/14] s390x: virtio-mem support
Date: Wed, 13 Nov 2024 15:46:56 +0100 [thread overview]
Message-ID: <07ca4492-1590-4cc6-94a1-0eea417da59e@redhat.com> (raw)
In-Reply-To: <20241008105455.2302628-1-david@redhat.com>
On 08.10.24 12:54, David Hildenbrand wrote:
> 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 is available at [3].
>
> [1] https://lkml.kernel.org/r/20240906101658.514470-1-pbonzini@redhat.com
> [2] https://gitlab.com/davidhildenbrand/s390x-os-virt-spec
> [3] https://lkml.kernel.org/r/20240910191541.2179655-6-david@redhat.com
Gentle ping (and thanks to Thomas for the review!).
I assume the kernel portion will go upstream in the next merge window.
I'd like get the QEMU parts merged soon after that.
9.2 is going to get released in roughly one month, so there is still time.
@Thomas, this is mostly s390x stuff, so I guess it should go through the
s390x tree? But I could also take this through my "memory devices" tree.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-11-13 14:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 10:54 [PATCH v2 00/14] s390x: virtio-mem support David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 01/14] s390x/s390-virtio-ccw: don't crash on weird RAM sizes David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 02/14] s390x/s390-virtio-hcall: remove hypercall registration mechanism David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 03/14] s390x/s390-virtio-hcall: prepare for more diag500 hypercalls David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 04/14] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 05/14] s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to machine code David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 06/14] s390x: introduce s390_get_memory_limit() David Hildenbrand
2024-11-06 17:08 ` Thomas Huth
2024-10-08 10:54 ` [PATCH v2 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 08/14] s390x/s390-stattrib-kvm: prepare for memory devices and sparse memory layouts David Hildenbrand
2024-11-07 13:59 ` Thomas Huth
2024-10-08 10:54 ` [PATCH v2 09/14] s390x/s390-skeys: prepare for memory devices David Hildenbrand
2024-12-13 12:36 ` Thomas Huth
2024-10-08 10:54 ` [PATCH v2 10/14] s390x/s390-virtio-ccw: " David Hildenbrand
2024-12-13 12:40 ` Thomas Huth
2024-12-13 14:21 ` David Hildenbrand
2024-12-13 15:35 ` Thomas Huth
2024-10-08 10:54 ` [PATCH v2 11/14] s390x/pv: " David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 12/14] s390x: remember the maximum page size David Hildenbrand
2024-12-13 12:43 ` Thomas Huth
2024-10-08 10:54 ` [PATCH v2 13/14] s390x/virtio-ccw: add support for virtio based memory devices David Hildenbrand
2024-10-08 10:54 ` [PATCH v2 14/14] s390x: virtio-mem support David Hildenbrand
2024-10-10 7:49 ` [PATCH v2 00/14] " Mario Casquero
2024-11-13 14:46 ` David Hildenbrand [this message]
2024-12-12 21:52 ` David Hildenbrand
2024-12-13 12:35 ` Thomas Huth
2024-12-13 14:26 ` David Hildenbrand
2024-12-16 21:18 ` David Hildenbrand
2024-12-18 16:48 ` Christian Borntraeger
2024-12-19 14:49 ` 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=07ca4492-1590-4cc6-94a1-0eea417da59e@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=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 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).