On Wed, Jul 10, 2024 at 11:12:34AM -0700, Daniel Verkamp wrote: > On Wed, Jul 10, 2024 at 4:43 AM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > virtio balloon communicates to the core that in some > > configurations vq #s are non-contiguous by setting name > > pointer to NULL. > > > > Unfortunately, core then turned around and just made them > > contiguous again. Result is that driver is out of spec. > > Thanks for fixing this - I think the overall approach of the patch looks good. > > > Implement what the API was supposed to do > > in the 1st place. Compatibility with buggy hypervisors > > is handled inside virtio-balloon, which is the only driver > > making use of this facility, so far. > > In addition to virtio-balloon, I believe the same problem also affects > the virtio-fs device, since queue 1 is only supposed to be present if > VIRTIO_FS_F_NOTIFICATION is negotiated, and the request queues are > meant to be queue indexes 2 and up. From a look at the Linux driver > (virtio_fs.c), it appears like it never acks VIRTIO_FS_F_NOTIFICATION > and assumes that request queues start at index 1 rather than 2, which > looks out of spec to me, but the current device implementations (that > I am aware of, anyway) are also broken in the same way, so it ends up > working today. Queue numbering in a spec-compliant device and the > current Linux driver would mismatch; what the driver considers to be > the first request queue (index 1) would be ignored by the device since > queue index 1 has no function if F_NOTIFICATION isn't negotiated. Oh, thanks a lot for pointing this out! I see so this patch is no good as is, we need to add a workaround for virtio-fs first. QEMU workaround is simple - just add an extra queue. But I did not reasearch how this would interact with vhost-user.
