Re: [PATCH v1] s390/virtio_ccw: don't allocate/assign airqs for non-existing queues

From: David Hildenbrand
Date: Mon Apr 07 2025 - 04:39:16 EST


On 07.04.25 10:17, David Hildenbrand wrote:
On 07.04.25 09:52, Michael S. Tsirkin wrote:
On Fri, Apr 04, 2025 at 05:39:10PM +0200, Halil Pasic wrote:

Not perfect, but AFAIKS, not horrible.

It is like it is. QEMU does queue exist if the corresponding feature
is offered by the device, and that is what we have to live with.

I don't think we can live with this properly though.
It means a guest that does not know about some features
does not know where to find things.

Please describe a real scenario, I'm missing the point.

Whoever adds new feat_X *must be aware* about all previous features,
otherwise we'd be reusing feature bits and everything falls to pieces.


So now, I am inclined to add linux code to work with current qemu and
with spec compliant one, and add qemu code to work with current linux
and spec compliant one.

Document the bug in the spec, maybe, in a non conformance section.

I'm afraid this results in a lot of churn without really making things
better.

IMHO, documenting things how they actually behave, and maybe moving
towards fixed queue indexes for new features is the low hanging fruit.

As raised, it's not just qemu+linux, it's *at least* also cloud-hypervisor.

I'm digging for other virtio-balloon implementations.


virtio-win: https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/Balloon/sys/balloon.c

-> Does not support hinting/reporting -> no problem


libkrun: https://github.com/containers/libkrun/blob/main/src/devices/src/virtio/balloon/device.rs

-> Hard-codes queue indexes but always seems to offer all features
-> Offers VIRTIO_BALLOON_F_FREE_PAGE_HINT and VIRTIO_BALLOON_F_STATS_VQ
even though it doesn't seem to implement them (device-triggered, so
nothing to do probably?)
-> Actually seems to implements VIRTIO_BALLOON_F_REPORTING


crossvm: https://github.com/google/crosvm/blob/main/devices/src/virtio/balloon.rs

-> Hard-codes queue numbers; does *not* offer/implement
VIRTIO_BALLOON_F_STATS_VQ but does offer VIRTIO_BALLOON_F_STATS_VQ
and VIRTIO_BALLOON_F_DEFLATE_ON_OOM.

-> Implements something that is not in the virtio-spec

const VIRTIO_BALLOON_F_WS_REPORTING: u32 = 8; // Working Set Reporting virtqueues

and

const WS_DATA_VQ: usize = 5;
const WS_OP_VQ: usize = 6;


IIUC, Linux inside cross-vm might actually be problematic? They would disagree on the virtqueue for free-page-reporting


Maybe I am missing something, it's a mess ...

--
Cheers,

David / dhildenb