From: Cornelia Huck <cohuck@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
qemu-s390x@nongnu.org,
Christian Borntraeger <borntraeger@linux.ibm.com>,
David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, Eric Farman <farman@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH 01/10] hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types
Date: Tue, 07 Jan 2025 13:59:23 +0100 [thread overview]
Message-ID: <874j2abx04.fsf@redhat.com> (raw)
In-Reply-To: <20250103144232.520383-2-thuth@redhat.com>
On Fri, Jan 03 2025, Thomas Huth <thuth@redhat.com> wrote:
> They are older than 6 years, so according to our machine support
> policy, they can be removed now.
>
> This removes the requirements for the storage keys "migration-enabled"
> property which will be removed in the next patch. It also removes
> the code that sets "max_revision" to 0 for some CCW devices, but
> the relating code in virtio-ccw.c indicates that 0 could have also
> been in use for other machines types < 5.1, so further clean-up for
> code related to "max_revision" won't be done yet.
These are two different issues:
- QEMU 2.4 and earlier _defaulted_ to legacy virtio devices (enforced by
setting max_revision to 0)
- QEMU 5.0 and earlier _allowed_ virtio device types to be configured as
legacy devices that did not actually support legacy (e.g. virtio-gpu),
there's a compat value to allow a max_revision of 0 for those old
machine types
So that's not a problem -- but I wonder whether we had missed the boat
elsewhere, when we introduced revisions > 1 (nothing much we can do now
if that is the case, though.)
I also don't think we actually want to remove max_revision anyway, as it
could also be used for non-compat related things (e.g. to accommodate a
known buggy driver.)
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> hw/s390x/s390-virtio-ccw.c | 37 -------------------------------------
> 1 file changed, 37 deletions(-)
The patch itself LGTM.
next prev parent reply other threads:[~2025-01-07 13:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 14:42 [PATCH 00/10] hw/s390x: Remove deprecated machine types 2.4 up to 2.8 Thomas Huth
2025-01-03 14:42 ` [PATCH 01/10] hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types Thomas Huth
2025-01-07 11:03 ` Philippe Mathieu-Daudé
2025-01-07 11:06 ` Philippe Mathieu-Daudé
2025-01-07 12:59 ` Cornelia Huck [this message]
2025-01-03 14:42 ` [PATCH 02/10] hw/s390x/s390-skeys: Remove the "migration-enabled" property Thomas Huth
2025-01-07 13:00 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 03/10] hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine type Thomas Huth
2025-01-07 13:01 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 04/10] hw/s390x: Remove the "ri_allowed" switch Thomas Huth
2025-01-07 13:03 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 05/10] hw/s390x/ipl: Remove the "iplbext_migration" property Thomas Huth
2025-01-07 11:04 ` Philippe Mathieu-Daudé
2025-01-07 13:04 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 06/10] hw/s390x/css-bridge: Remove the "css_dev_path" property Thomas Huth
2025-01-07 11:05 ` Philippe Mathieu-Daudé
2025-01-07 13:06 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 07/10] hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine type Thomas Huth
2025-01-07 13:07 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 08/10] hw/s390x: Remove the cpu_model_allowed flag and related code Thomas Huth
2025-01-07 13:09 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 09/10] hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine type Thomas Huth
2025-01-07 13:10 ` Cornelia Huck
2025-01-03 14:42 ` [PATCH 10/10] hw/s390x: Remove the "adapter_routes_max_batch" property from the flic Thomas Huth
2025-01-07 11:06 ` Philippe Mathieu-Daudé
2025-01-07 13:11 ` Cornelia Huck
2025-01-07 10:22 ` [PATCH 00/10] hw/s390x: Remove deprecated machine types 2.4 up to 2.8 Christian Borntraeger
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=874j2abx04.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.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).