On Tue, Apr 18, 2023 at 06:37:04PM +0200, Andrey Ryabinin wrote: > 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.
The problem with hacks like this is the problem proliferates. What are those guests and how hard are they to fix? -- MST
