@samitouri / QOSamiQemu / commits / e777ba135f

vhost-user-blk-server: do not advertise VIRTIO_BLK_F_SIZE_MAX with size_max=0

The QSD vhost-user-blk backend advertises VIRTIO_BLK_F_SIZE_MAX but sets size_max=0 in config, creating a contradictory state. The feature bit tells the guest that size_max is valid, but the value is zero. Windows viostor trusts the feature bit, reads size_max=0, and uses it in scatter-gather calculations producing zero-length segments that hang I/O. The disk appears empty (no GPT, no partitions), causing INACCESSIBLE_BOOT_DEVICE BSOD. Linux tolerates this because blk_validate_limits() silently corrects max_segment_size=0 to BLK_MAX_SEGMENT_SIZE (65536). This affects any VMM using QSD as a vhost-user-blk backend (QEMU, Cloud Hypervisor, etc.), since both pass through SIZE_MAX from the backend to the guest via feature intersection. Remove VIRTIO_BLK_F_SIZE_MAX from the backend feature bits. The size_max config field remains zero but is now ignored by guests since the feature is not negotiated. Signed-off-by: Max Makarov <maxpain@linux.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20260331152856.1802-1-maxpain@linux.com>

Max Makarov committed Mar 31, 2026 at 18:28 UTC e777ba135f2a1a171cdcd468cfb29e89f1b27fd5
1 file changed +1 -1
block/export/vhost-user-blk-server.c
+1 -1
@@ -119,7 +119,7 @@ static uint64_t vu_blk_get_features(VuDev *dev)
119 uint64_t features;
120 VuServer *server = container_of(dev, VuServer, vu_dev);
121 VuBlkExport *vexp = container_of(server, VuBlkExport, vu_server);
122 - features = 1ull << VIRTIO_BLK_F_SIZE_MAX |
122 + features =
123 1ull << VIRTIO_BLK_F_SEG_MAX |
124 1ull << VIRTIO_BLK_F_TOPOLOGY |
125 1ull << VIRTIO_BLK_F_BLK_SIZE |