bwlp/qemu.git/include/hw/virtio, branch spice_video_codecs

include/hw: VM state takes precedence in virtio_device_should_start

2022-12-01T07:30:18+00:00

The VM status should always preempt the device status for these checks. This ensures the device is in the correct state when we suspend the VM prior to migrations. This restores the checks to the order they where in before the refactoring moved things around. While we are at it lets improve our documentation of the various fields involved and document the two functions. Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started) Fixes: 259d69c00b (hw/virtio: introduce virtio_device_should_start) Signed-off-by: Alex Bennée Tested-by: Christian Borntraeger Reviewed-by: Michael S. Tsirkin Message-Id: <20221130112439.2527228-6-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin

hw/virtio: generalise CHR_EVENT_CLOSED handling

2022-12-01T07:30:13+00:00

..and use for both virtio-user-blk and virtio-user-gpio. This avoids the circular close by deferring shutdown due to disconnection until a later point. virtio-user-blk already had this mechanism in place so generalise it as a vhost-user helper function and use for both blk and gpio devices. While we are at it we also fix up vhost-user-gpio to re-establish the event handler after close down so we can reconnect later. Signed-off-by: Alex Bennée Reviewed-by: Michael S. Tsirkin Reviewed-by: Raphael Norwitz Message-Id: <20221130112439.2527228-5-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin

hw/virtio: add started_vu status field to vhost-user-gpio

2022-12-01T07:30:09+00:00

As per the fix to vhost-user-blk in f5b22d06fb (vhost: recheck dev state in the vhost_migration_log routine) we really should track the connection and starting separately. Signed-off-by: Alex Bennée Reviewed-by: Michael S. Tsirkin Message-Id: <20221130112439.2527228-4-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin

vhost: enable vrings in vhost_dev_start() for vhost-user devices

2022-12-01T07:30:04+00:00

Commit 02b61f38d3 ("hw/virtio: incorporate backend features in features") properly negotiates VHOST_USER_F_PROTOCOL_FEATURES with the vhost-user backend, but we forgot to enable vrings as specified in docs/interop/vhost-user.rst: If ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been negotiated, the ring starts directly in the enabled state. If ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, the ring is initialized in a disabled state and is enabled by ``VHOST_USER_SET_VRING_ENABLE`` with parameter 1. Some vhost-user front-ends already did this by calling vhost_ops.vhost_set_vring_enable() directly: - backends/cryptodev-vhost.c - hw/net/virtio-net.c - hw/virtio/vhost-user-gpio.c But most didn't do that, so we would leave the vrings disabled and some backends would not work. We observed this issue with the rust version of virtiofsd [1], which uses the event loop [2] provided by the vhost-user-backend crate where requests are not processed if vring is not enabled. Let's fix this issue by enabling the vrings in vhost_dev_start() for vhost-user front-ends that don't already do this directly. Same thing also in vhost_dev_stop() where we disable vrings. [1] https://gitlab.com/virtio-fs/virtiofsd [2] https://github.com/rust-vmm/vhost/blob/240fc2966/crates/vhost-user-backend/src/event_loop.rs#L217 Fixes: 02b61f38d3 ("hw/virtio: incorporate backend features in features") Reported-by: German Maglione Tested-by: German Maglione Signed-off-by: Stefano Garzarella Acked-by: Raphael Norwitz Message-Id: <20221123131630.52020-1-sgarzare@redhat.com> Signed-off-by: Alex Bennée Reviewed-by: Michael S. Tsirkin Message-Id: <20221130112439.2527228-3-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin

virtio-net: fix for heap-buffer-overflow

2022-11-10T15:18:55+00:00

Run shell script: cat << EOF | valgrind qemu-system-i386 -display none -machine accel=qtest, -m \ 512M -M q35 -nodefaults -device virtio-net,netdev=net0 -netdev \ user,id=net0 -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xc000 outl 0xcf8 0x80000804 outl 0xcfc 0x01 outl 0xc00d 0x0200 outl 0xcf8 0x80000890 outb 0xcfc 0x4 outl 0xcf8 0x80000889 outl 0xcfc 0x1c000000 outl 0xcf8 0x80000893 outw 0xcfc 0x100 EOF Got: ==68666== Invalid read of size 8 ==68666== at 0x688536: virtio_net_queue_enable (virtio-net.c:575) ==68666== by 0x6E31AE: memory_region_write_accessor (memory.c:492) ==68666== by 0x6E098D: access_with_adjusted_size (memory.c:554) ==68666== by 0x6E4DB3: memory_region_dispatch_write (memory.c:1521) ==68666== by 0x6E31AE: memory_region_write_accessor (memory.c:492) ==68666== by 0x6E098D: access_with_adjusted_size (memory.c:554) ==68666== by 0x6E4DB3: memory_region_dispatch_write (memory.c:1521) ==68666== by 0x6EBCD3: flatview_write_continue (physmem.c:2820) ==68666== by 0x6EBFBF: flatview_write (physmem.c:2862) ==68666== by 0x6EF5E7: address_space_write (physmem.c:2958) ==68666== by 0x6DFDEC: cpu_outw (ioport.c:70) ==68666== by 0x6F6DF0: qtest_process_command (qtest.c:480) ==68666== Address 0x29087fe8 is 24 bytes after a block of size 416 in arena "client" That is reported by Alexander Bulekov. https://gitlab.com/qemu-project/qemu/-/issues/1309 Here, the queue_index is the index of the cvq, but in some cases cvq does not have the corresponding NetClientState, so overflow appears. I add a check here, ignore illegal queue_index and cvq queue_index. Note the queue_index is below the VIRTIO_QUEUE_MAX but greater or equal than cvq index could hit this. Other devices are similar. Fixes: 7f863302 ("virtio-net: support queue_enable") Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1309 Reported-by: Alexander Bulekov Signed-off-by: Xuan Zhuo Message-Id: <20221110095739.130393-1-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

hw/virtio: introduce virtio_device_should_start

2022-11-07T19:08:18+00:00

The previous fix to virtio_device_started revealed a problem in its use by both the core and the device code. The core code should be able to handle the device "starting" while the VM isn't running to handle the restoration of migration state. To solve this duel use introduce a new helper for use by the vhost-user backends who all use it to feed a should_start variable. We can also pick up a change vhost_user_blk_set_status while we are at it which follows the same pattern. Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started) Signed-off-by: Alex Bennée Cc: "Michael S. Tsirkin" Message-Id: <20221107121407.1010913-1-alex.bennee@linaro.org>

vhost: expose vhost_virtqueue_stop()

2022-11-07T18:12:20+00:00

Expose vhost_virtqueue_stop(), we need to use it when resetting a virtqueue. Signed-off-by: Kangjie Xu Signed-off-by: Xuan Zhuo Acked-by: Jason Wang Message-Id: <20221017092558.111082-9-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

vhost: expose vhost_virtqueue_start()

2022-11-07T18:12:20+00:00

Expose vhost_virtqueue_start(), we need to use it when restarting a virtqueue. Signed-off-by: Kangjie Xu Signed-off-by: Xuan Zhuo Acked-by: Jason Wang Message-Id: <20221017092558.111082-8-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

virtio-pci: support queue reset

2022-11-07T18:12:20+00:00

PCI devices support vq reset. Based on this function, the driver can adjust the size of the ring, and quickly recycle the buffer in the ring. The migration of the virtio devices will not happen during a reset operation. This is becuase the global iothread lock is held. Migration thread also needs the lock. As a result, when migration of virtio devices starts, the 'reset' status of VirtIOPCIQueue will always be 0. Thus, we do not need to add it in vmstate_virtio_pci_modern_queue_state. Signed-off-by: Xuan Zhuo Signed-off-by: Kangjie Xu Acked-by: Jason Wang Message-Id: <20221017092558.111082-6-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

virtio: core: vq reset feature negotation support

2022-11-07T18:12:20+00:00

A a new command line parameter "queue_reset" is added. Meanwhile, the vq reset feature is disabled for pre-7.2 machines. Signed-off-by: Kangjie Xu Signed-off-by: Xuan Zhuo Acked-by: Jason Wang Message-Id: <20221017092558.111082-5-xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin