On 4/18/23 07:13, Raphael Norwitz wrote: > Hey Andrey - apologies for the late reply here. > > It sounds like you are dealing with a buggy guest, rather than a QEMU issue.
No arguing here, the guest is buggy. However, the issue with QEMU is that virtio-blk tolerate such buggy guest while vhost-user-blk is not. We've been using virtio-blk in our cloud for a while and recently started switching to vhost-user-blk which led us to discover this problem. >> On Apr 10, 2023, at 11:39 AM, Andrey Ryabinin <a...@yandex-team.com> wrote: >> >> >> >> On 4/10/23 10:35, Andrey Ryabinin wrote: >>> Some guests hang on boot when using the vhost-user-blk-pci device, >>> but boot normally when using the virtio-blk device. The problem occurs >>> because the guest advertises VIRTIO_F_VERSION_1 but kicks the virtqueue >>> before setting VIRTIO_CONFIG_S_DRIVER_OK, causing vdev->start_on_kick to > > Virtio 1.1 Section 3.1.1, says during setup “[t]he driver MUST NOT notify the > device before setting DRIVER_OK.” > > Therefore what you are describing is buggy guest behavior. Sounds like the > driver should be made to either > - not advertise VIRTIO_F_VERSION_1 > - not kick before setting VIRTIO_CONFIG_S_DRIVER_OK > > If anything, the virtio-blk virtio_blk_handle_output() function should > probably check start_on_kick? > Ideally this should have been done from the start. But if we do it now we'll just break these guests.
