On Mon, Nov 28, 2022 at 05:14:44AM -0500, Michael S. Tsirkin wrote: > On Mon, Nov 28, 2022 at 10:10:01AM +0800, Li Zetao wrote: > > This patchset fixes similar issue, the root cause of the > > problem is that the virtqueues are not stopped on error > > handling path. > > I've been thinking about this. > Almost all drivers are affected. > > The reason really is that it used to be the right thing to do: > On legacy pci del_vqs writes 0 > into vq index and this resets the device as a side effect > (we actually do this multiple times, what e.g. writes of MSI vector > after the 1st reset do I have no idea). > > mmio ccw and modern pci don't. > > Given this has been with us for a while I am inlined to look for > a global solution rather than tweaking each driver. > > Given many drivers are supposed to work on legacy too, we know del_vqs > includes a reset for many of them. So I think I see a better way to do > this: > > Add virtio_reset_device_and_del_vqs() > > and convert all drivers to that. > > When doing this, we also need to/can fix a related problem (and related > to the hardening that Jason Wang was looking into): > virtio_reset_device is inherently racy: vq interrupts could > be in flight when we do reset. We need to prevent handlers from firing in > the window between reset and freeing the irq, so we should first > free irqs and only then start changing the state by e.g. > device reset. > > > Quite a lot of core work here. Jason are you still looking into > hardening? > Li Zetao, Jason, any updates. You guys looking into this? > > > Li Zetao (4): > > 9p: Fix probe failed when modprobe 9pnet_virtio > > virtio-mem: Fix probe failed when modprobe virtio_mem > > virtio-input: Fix probe failed when modprobe virtio_input > > virtio-blk: Fix probe failed when modprobe virtio_blk > > > > drivers/block/virtio_blk.c | 1 + > > drivers/virtio/virtio_input.c | 1 + > > drivers/virtio/virtio_mem.c | 1 + > > net/9p/trans_virtio.c | 1 + > > 4 files changed, 4 insertions(+) > > > > -- > > 2.25.1 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization