vhost_user_blk_get_features() unconditionally advertises
VIRTIO_BLK_F_SIZE_MAX regardless of what the backend reports in
its config. The built-in QSD vhost-user-blk backend sets
size_max=0, creating a contradictory state where the feature bit
tells the guest that size_max is valid but the value is zero.
The in-process virtio-blk device does not advertise
VIRTIO_BLK_F_SIZE_MAX (it also sets size_max=0 in config), so
guests never see this contradiction with native virtio-blk.
Linux tolerates size_max=0 because blk_validate_limits() silently
corrects max_segment_size=0 to BLK_MAX_SEGMENT_SIZE (65536).
Windows viostor, however, trusts the feature bit and uses the raw
size_max=0 in its scatter-gather calculations, producing
zero-length segments that hang I/O. The disk appears empty to
Windows (no GPT, no partitions), causing INACCESSIBLE_BOOT_DEVICE.
Stop force-adding VIRTIO_BLK_F_SIZE_MAX in the frontend. The
feature remains in user_feature_bits[], so backends that properly
advertise it with a valid config value will still work.
Signed-off-by: Max Makarov <maxpain@linux.com>
---
v2:
- Remove the VIRTIO_BLK_F_SIZE_MAX feature bit from the frontend
instead of setting size_max=4096 in the backend config [Kevin Wolf]
- Fix incorrect claim about Linux PAGE_SIZE fallback
- Drop unrelated Buglink tags
---
hw/block/vhost-user-blk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index c151e83..7ba6562 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -273,7 +273,6 @@ static uint64_t vhost_user_blk_get_features(VirtIODevice *vdev,
VHostUserBlk *s = VHOST_USER_BLK(vdev);
/* Turn on pre-defined features */
- virtio_add_feature(&features, VIRTIO_BLK_F_SIZE_MAX);
virtio_add_feature(&features, VIRTIO_BLK_F_SEG_MAX);
virtio_add_feature(&features, VIRTIO_BLK_F_GEOMETRY);
virtio_add_feature(&features, VIRTIO_BLK_F_TOPOLOGY);
--
2.53.0