From: Cornelia Huck <cohuck@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>,
Jaehoon Kim <jhkim@linux.ibm.com>,
qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Cc: richard.henderson@linaro.org, iii@linux.ibm.com,
david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com,
farman@linux.ibm.com
Subject: Re: [PATCH RFC v1 1/1] hw/s390x/ccw: Disable legacy virtio-pci by default (v11.1+)
Date: Mon, 20 Apr 2026 14:47:52 +0200 [thread overview]
Message-ID: <874il5u7bb.fsf@redhat.com> (raw)
In-Reply-To: <530e4dc5-3a3f-4556-bfd6-d6e9e5b5da0e@linux.ibm.com>
On Mon, Apr 20 2026, Matthew Rosato <mjrosato@linux.ibm.com> wrote:
> On 4/20/26 6:12 AM, Cornelia Huck wrote:
>> On Fri, Apr 17 2026, Jaehoon Kim <jhkim@linux.ibm.com> wrote:
>>
>>> On the s390 Linux kernel, IO_SPACE_LIMIT has been 0 since the initial
>>> zPCI implementation (commit cd24834130ac "s390/pci: base support"),
>>> making I/O BARs unusable.
>>>
>>> However, when virtio-pci devices operate in transitional mode, QEMU
>>> unconditionally exposes the legacy interface via BAR0. This results in
>>> firmware warnings during PCI enumeration, such as:
>>>
>>> pci 0005:00:00.0: [Firmware Bug]: BAR 0: invalid; can't size
>>>
>>> even though BAR0 is never usable on the s390 kernel.
>>>
>>> Close this gap by disabling legacy virtio-pci support starting from
>>> machine version 11.1. This effectively makes virtio-pci devices
>>> non-transitional and prevents the creation of the unusable legacy I/O
>>> BAR.
>>>
>>> This introduces s390x-specific global compatibility properties that
>>> set disable-legacy=on as the default for virtio-pci devices. Machine
>>> versions v11.0 and earlier set disable-legacy=off to maintain their
>>> original default behavior (legacy support enabled), ensuring VMs
>>> created with those versions continue to work identically.
>>>
>>> Users can override the default on the command line if needed:
>>> - On v11.1+: -global virtio-pci.disable-legacy=off (to enable legacy)
>>> - On v11.0-: -global virtio-pci.disable-legacy=on (to disable legacy)
>>
>> Makes sense to disable legacy virtio-pci devices, if they cannot work
>> anyway. I'm wondering if we want to have a generic "no legacy" switch as
>> well. I remember a patch from some time ago, but that was concerned with
>> endianness IIRC.
>
> Thanks Connie, I was hoping to get your input on this idea.
>
> By generic, do you mean disabling legacy virtio-pci (and legacy
> virtio-ccw?) across QEMU for all platforms vs only disabling it for s390x?
If we are moving towards multi-arch binaries, it would need to be the
latter; another benefit would be removing legacy bits from the virtio
core. But I think we'd still need quite some time before we get there
(virtio-pci switched to modern by default later than virtio-ccw.)
>
>>
>> Anyway, we cannot turn off pre-1.0 for virtio-ccw at the moment, because
>> the bios still uses legacy virtio. Would be a bit of an effort to change
>> that, but still sounds like a good idea to me.
>>
>
> Good point, hadn't thought about that and I guess it would be a pre-req
> if you really wanted to disable legacy virtio everywhere; we can
> certainly put this on our todo list for later, but I'd still like a
> patch like this one to fix the awkward s390x virtio-pci situation now.
Yep, this patch is fine for the current situation, I guess legacy
virtio-ccw will stay around for a bit longer (and there's no urgent need
to remove support for it as long as the virtio core still supports
legacy easily.)
next prev parent reply other threads:[~2026-04-20 12:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 15:43 [PATCH RFC v1 0/1] hw/s390x/ccw: Disable legacy mode Jaehoon Kim
2026-04-17 15:43 ` [PATCH RFC v1 1/1] hw/s390x/ccw: Disable legacy virtio-pci by default (v11.1+) Jaehoon Kim
2026-04-17 15:49 ` Mohamed Mediouni
2026-04-20 10:12 ` Cornelia Huck
2026-04-20 12:29 ` Matthew Rosato
2026-04-20 12:47 ` Cornelia Huck [this message]
2026-04-20 13:53 ` JAEHOON KIM
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=874il5u7bb.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=jhkim@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
/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.