On 7/29/26 08:12, Michael Tokarev wrote:
On 7/29/26 02:22, Michael S. Tsirkin wrote:
On Tue, Jul 28, 2026 at 11:17:34PM +0300, Michael Tokarev wrote:
..
So this whole change, for older versions, becomes just:
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2572,6 +2572,8 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int
queue_size,
if (i == VIRTIO_QUEUE_MAX || queue_size > VIRTQUEUE_MAX_SIZE)
abort();
+ queue_size = VIRTQUEUE_MAX_SIZE; /* fixed properly in 11.1. */
+
Or you can stick to upstream and add the compat entry for 11.0.
Compat entry for 11.0 which will never be used?
With a non-obvious logic which boils down to this single line?
Or what do you mean?
BTW, can't this logic be implemented without a compat property in
the first place? This x-override-queue-size seems like a hack.
or a.. twisted way to compare a machine version.
Can't this very place become
if (machine_version < 11.1) {
queue_size = VIRTQUEUE_MAX_SIZE;
}
instead of using this indirect property?
Michael, I still don't understand what we're doing here and - now -
why do we need to distinguish between old and new machine types at all.
Behavior before the fixes:
qemu always reported queue size to be the maximum allowed one (1024),
even if actual queue size requested and allocated was smaller
qemu accepted requests to elements past the allocated size, which
allowed to read/write past the allocated buffer - which can't be
considered part of ABI, obviously :)
Behavior after the fixes, for new machine types:
qemu reports actually requested and allocated queue size
qemu properly disallows access past the allocated queue size
What would break if we switch to the new behavior unconditionally,
regardless of the machine types?
I don't understand why do you suggest to implement the same logic for
older/stable qemu versions if it will always evaluate to allocating
the max size for the queue regardless of the requested size.
Thanks,
/mjt
