From: Max Makarov <[email protected]> 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 <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-Id: <[email protected]> --- block/export/vhost-user-blk-server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/export/vhost-user-blk-server.c b/block/export/vhost-user-blk-server.c index 67912a3e17..46c0d303df 100644 --- a/block/export/vhost-user-blk-server.c +++ b/block/export/vhost-user-blk-server.c @@ -119,7 +119,7 @@ static uint64_t vu_blk_get_features(VuDev *dev) uint64_t features; VuServer *server = container_of(dev, VuServer, vu_dev); VuBlkExport *vexp = container_of(server, VuBlkExport, vu_server); - features = 1ull << VIRTIO_BLK_F_SIZE_MAX | + features = 1ull << VIRTIO_BLK_F_SEG_MAX | 1ull << VIRTIO_BLK_F_TOPOLOGY | 1ull << VIRTIO_BLK_F_BLK_SIZE | -- MST
