The QSD vhost-user-blk export sets size_max=0 in the virtio config,
but the vhost-user-blk frontend unconditionally advertises
VIRTIO_BLK_F_SIZE_MAX. This creates a spec-violating state: the
feature bit tells the guest that size_max is valid, but the value
is 0.

Native virtio-blk-pci does not advertise VIRTIO_BLK_F_SIZE_MAX when
size_max=0, so guests never see this contradiction there.

The Windows viostor driver trusts the feature bit and uses size_max=0
in its MaximumTransferLength calculation, producing malformed
scatter-gather requests. The disk appears completely empty to Windows
(no GPT, no partitions in diskpart), causing INACCESSIBLE_BOOT_DEVICE
BSOD. Linux is unaffected because its virtio_blk driver falls back to
PAGE_SIZE when size_max=0.

Set size_max to 4096 (PAGE_SIZE) to provide a valid segment size limit
that matches what Linux assumes as a fallback. This fixes Windows
Server 2025 (and likely all Windows versions) booting from
vhost-user-blk.

Buglink: https://github.com/spdk/spdk/issues/3199
Buglink: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/692
Signed-off-by: Max Makarov <maxpain@linux.com>
---
 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 e89422b..827502d 100644
--- a/block/export/vhost-user-blk-server.c
+++ b/block/export/vhost-user-blk-server.c
@@ -240,7 +240,7 @@ vu_blk_initialize_config(BlockDriverState *bs,
     config->capacity =
         cpu_to_le64(bdrv_getlength(bs) >> VIRTIO_BLK_SECTOR_BITS);
     config->blk_size = cpu_to_le32(blk_size);
-    config->size_max = cpu_to_le32(0);
+    config->size_max = cpu_to_le32(4096);
     config->seg_max = cpu_to_le32(128 - 2);
     config->min_io_size = cpu_to_le16(1);
     config->opt_io_size = cpu_to_le32(1);
-- 
2.53.0

Am 30.03.2026 um 17:13 hat Max Makarov geschrieben:
> The QSD vhost-user-blk export sets size_max=0 in the virtio config,
> but the vhost-user-blk frontend unconditionally advertises
> VIRTIO_BLK_F_SIZE_MAX. This creates a spec-violating state: the
> feature bit tells the guest that size_max is valid, but the value
> is 0.
> 
> Native virtio-blk-pci does not advertise VIRTIO_BLK_F_SIZE_MAX when
> size_max=0, so guests never see this contradiction there.
> 
> The Windows viostor driver trusts the feature bit and uses size_max=0
> in its MaximumTransferLength calculation, producing malformed
> scatter-gather requests. The disk appears completely empty to Windows
> (no GPT, no partitions in diskpart), causing INACCESSIBLE_BOOT_DEVICE
> BSOD. Linux is unaffected because its virtio_blk driver falls back to
> PAGE_SIZE when size_max=0.

Where is this fallback to PAGE_SIZE?

I can see that in virtblk_read_limits(), not setting the flag would
leave lim->max_segment_size at max_dma_size (capped at U32_MAX, which I
think it will actually be in the normal case), whereas setting it makes
it 0. If it's 0, blk_validate_limits() later updates it to
BLK_MAX_SEGMENT_SIZE, which is 65536.

> Set size_max to 4096 (PAGE_SIZE) to provide a valid segment size limit
> that matches what Linux assumes as a fallback. This fixes Windows
> Server 2025 (and likely all Windows versions) booting from
> vhost-user-blk.

4096 is really small and doesn't feel very optimal.

Why don't we just do what the in-process virtio-blk device does and
clear the VIRTIO_BLK_F_SIZE_MAX flag?

> Buglink: https://github.com/spdk/spdk/issues/3199
> Buglink: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/692
> Signed-off-by: Max Makarov <maxpain@linux.com>

The linked bug reports seems to be about a different bug, which has long
been addressed in both projects. Buglink should be used for bug reports
that are fixed with this patch (see docs/devel/submitting-a-patch.rst).

Kevin