* [PATCH] vhost-user-blk-server: fix size_max=0 breaking Windows guests
@ 2026-03-30 15:13 Max Makarov
2026-03-31 12:51 ` Kevin Wolf
0 siblings, 1 reply; 2+ messages in thread
From: Max Makarov @ 2026-03-30 15:13 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-block, Coiby Xu, Stefano Garzarella, Michael S . Tsirkin,
Kevin Wolf, Hanna Reitz, Max Makarov
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
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH] vhost-user-blk-server: fix size_max=0 breaking Windows guests
2026-03-30 15:13 [PATCH] vhost-user-blk-server: fix size_max=0 breaking Windows guests Max Makarov
@ 2026-03-31 12:51 ` Kevin Wolf
0 siblings, 0 replies; 2+ messages in thread
From: Kevin Wolf @ 2026-03-31 12:51 UTC (permalink / raw)
To: Max Makarov
Cc: qemu-devel, qemu-block, Coiby Xu, Stefano Garzarella,
Michael S . Tsirkin, Hanna Reitz, Max Makarov
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-03-31 12:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-30 15:13 [PATCH] vhost-user-blk-server: fix size_max=0 breaking Windows guests Max Makarov
2026-03-31 12:51 ` Kevin Wolf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.