summaryrefslogtreecommitdiffstats
path: root/hw/scsi/virtio-scsi.c
Commit message (Collapse)AuthorAgeFilesLines
* virtio-scsi: use scsi_device_getMaxim Levitsky2020-10-121-8/+13
| | | | | | | | | | | | | | | | This will help us to avoid the scsi device disappearing after we took a reference to it. It doesn't by itself forbid case when we try to access an unrealized device Suggested-by: Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200913160259.32145-9-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20201006123904.610658-13-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* device-core: use RCU for list of children of a busMaxim Levitsky2020-10-121-1/+5
| | | | | | | | | | | | | | | | | | | | | This fixes the race between device emulation code that tries to find a child device to dispatch the request to (e.g a scsi disk), and hotplug of a new device to that bus. Note that this doesn't convert all the readers of the list but only these that might go over that list without BQL held. This is a very small first step to make this code thread safe. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200913160259.32145-5-mlevitsk@redhat.com> [Use RCU_READ_LOCK_GUARD in more places, adjust testcase now that the delay in DEVICE_DELETED due to RCU is more consistent. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20201006123904.610658-9-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi-pci: default num_queues to -smp NStefan Hajnoczi2020-08-271-1/+5
| | | | | | | | | | | | | | | | | | Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and vhost-user-scsi-pci request virtqueues to match the number of vCPUs. Other transports continue to default to 1 request virtqueue. A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are handled on the same vCPU that submitted the request. No IPI is necessary to complete an I/O request and performance is improved. The maximum number of MSI-X vectors and virtqueues limit are respected. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200818143348.310613-6-stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: introduce a constant for fixed virtqueuesStefan Hajnoczi2020-08-271-3/+4
| | | | | | | | | | | | | | | The event and control virtqueues are always present, regardless of the multi-queue configuration. Define a constant so that virtqueue number calculations are easier to read. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20200818143348.310613-5-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* qdev: Drop qbus_set_hotplug_handler() parameter @errpMarkus Armbruster2020-07-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qbus_set_hotplug_handler() is a simple wrapper around object_property_set_link(). object_property_set_link() fails when the property doesn't exist, is not settable, or its .check() method fails. These are all programming errors here, so passing &error_abort to qbus_set_hotplug_handler() is appropriate. Most of its callers do. Exceptions: * pcie_cap_slot_init(), shpc_init(), spapr_phb_realize() pass NULL, i.e. they ignore errors. * spapr_machine_init() passes &error_fatal. * s390_pcihost_realize(), virtio_serial_device_realize(), s390_pcihost_plug() pass the error to their callers. The latter two keep going after the error, which looks wrong. Drop the @errp parameter, and instead pass &error_abort to object_property_set_link(). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200630090351.1247703-15-armbru@redhat.com>
* qdev: Unrealize must not failMarkus Armbruster2020-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
* virtio: increase virtqueue size for virtio-scsi and virtio-blkDenis Plotnikov2020-02-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | The goal is to reduce the amount of requests issued by a guest on 1M reads/writes. This rises the performance up to 4% on that kind of disk access pattern. The maximum chunk size to be used for the guest disk accessing is limited with seg_max parameter, which represents the max amount of pices in the scatter-geather list in one guest disk request. Since seg_max is virqueue_size dependent, increasing the virtqueue size increases seg_max, which, in turn, increases the maximum size of data to be read/write from a guest disk. More details in the original problem statment: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html Suggested-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-id: 20200214074648.958-1-dplotnikov@virtuozzo.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* qdev: set properties with device_class_set_props()Marc-André Lureau2020-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: convert to new virtio_delete_queuePan Nengyuan2020-01-241-3/+3
| | | | | | | | | Use virtio_delete_queue to make it more clear. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200117075547.60864-3-pannengyuan@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: delete vqs in unrealize to avoid memleaksPan Nengyuan2020-01-241-0/+6
| | | | | | | | | | | | | | | | | | | | This patch fix memleaks when attaching/detaching virtio-scsi device, the memory leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 #3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912 #4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924 #5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 #6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224) /mnt/sdb/qemu/hw/core/qdev.c:865 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio: make seg_max virtqueue size dependentDenis Plotnikov2020-01-061-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the patch, seg_max parameter was immutable and hardcoded to 126 (128 - 2) without respect to queue size. This has two negative effects: 1. when queue size is < 128, we have Virtio 1.1 specfication violation: (2.6.5.3.1 Driver Requirements) seq_max must be <= queue_size. This violation affects the old Linux guests (ver < 4.14). These guests crash on these queue_size setups. 2. when queue_size > 128, as was pointed out by Denis Lunev <den@virtuozzo.com>, seg_max restrics guest's block request length which affects guests' performance making them issues more block request than needed. https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03721.html To mitigate this two effects, the patch adds the property adjusting seg_max to queue size automaticaly. Since seg_max is a guest visible parameter, the property is machine type managable and allows to choose between old (seg_max = 126 always) and new (seg_max = queue_size - 2) behaviors. Not to change the behavior of the older VMs, prevent setting the default seg_max_adjust value for older machine types. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-Id: <20191220140905.1718-2-dplotnikov@virtuozzo.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: don't enable notifications during pollingStefan Hajnoczi2020-01-051-2/+7
| | | | | | | | | | | | | | | | | | | | | | Virtqueue notifications are not necessary during polling, so we disable them. This allows the guest driver to avoid MMIO vmexits. Unfortunately the virtio-blk and virtio-scsi handler functions re-enable notifications, defeating this optimization. Fix virtio-blk and virtio-scsi emulation so they leave notifications disabled. The key thing to remember for correctness is that polling always checks one last time after ending its loop, therefore it's safe to lose the race when re-enabling notifications at the end of polling. There is a measurable performance improvement of 5-10% with the null-co block driver. Real-life storage configurations will see a smaller improvement because the MMIO vmexit overhead contributes less to latency. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191209210957.65087-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: basic packed virtqueue supportJason Wang2019-10-251-1/+2
| | | | | | | | | | | | | | | | This patch implements basic support for the packed virtqueue. Compare the split virtqueue which has three rings, packed virtqueue only have one which is supposed to have better cache utilization and more hardware friendly. Please refer virtio specification for more information. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20191025083527.30803-6-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* Include hw/qdev-properties.h lessMarkus Armbruster2019-08-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
* Include migration/qemu-file-types.h a lot lessMarkus Armbruster2019-08-161-0/+1
| | | | | | | | | | | | | | | | | In my "build everything" tree, changing migration/qemu-file-types.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The culprit is again hw/hw.h, which supposedly includes it for convenience. Include migration/qemu-file-types.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-10-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* virtio-scsi: fixed virtio_scsi_ctx_check failed when detaching scsi diskZhengui li2019-07-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a6f230c move blockbackend back to main AioContext on unplug. It set the AioContext of SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContex（if the scsi controller is configure with iothread）. So if there are having in-flight requests during unplug, a failing assertion happend. The bt is below: (gdb) bt #0 0x0000ffff86aacbd0 in raise () from /lib64/libc.so.6 #1 0x0000ffff86aadf7c in abort () from /lib64/libc.so.6 #2 0x0000ffff86aa6124 in __assert_fail_base () from /lib64/libc.so.6 #3 0x0000ffff86aa61a4 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000529118 in virtio_scsi_ctx_check (d=<optimized out>, s=<optimized out>, s=<optimized out>) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:246 #5 0x0000000000529ec4 in virtio_scsi_handle_cmd_req_prepare (s=0x2779ec00, req=0xffff740397d0) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:559 #6 0x000000000052a228 in virtio_scsi_handle_cmd_vq (s=0x2779ec00, vq=0xffff7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:603 #7 0x000000000052afa8 in virtio_scsi_data_plane_handle_cmd (vdev=<optimized out>, vq=0xffff7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:59 #8 0x000000000054d94c in virtio_queue_host_notifier_aio_poll (opaque=<optimized out>) at /home/qemu-4.0.0/hw/virtio/virtio.c:2452 assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. To avoid assertion failed, moving the "if" after qdev_simple_device_unplug_cb. In addition, to avoid another qemu crash below, add aio_disable_external before qdev_simple_device_unplug_cb, which disable the further processing of external clients when doing qdev_simple_device_unplug_cb. (gdb) bt #0 scsi_req_unref (req=0xffff6802c6f0) at hw/scsi/scsi-bus.c:1283 #1 0x00000000005294a4 in virtio_scsi_handle_cmd_req_submit (req=<optimized out>, s=<optimized out>) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:589 #2 0x000000000052a2a8 in virtio_scsi_handle_cmd_vq (s=s@entry=0x9c90e90, vq=vq@entry=0xffff7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:625 #3 0x000000000052afd8 in virtio_scsi_data_plane_handle_cmd (vdev=<optimized out>, vq=0xffff7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:60 #4 0x000000000054d97c in virtio_queue_host_notifier_aio_poll (opaque=<optimized out>) at /home/qemu-4.0.0/hw/virtio/virtio.c:2447 #5 0x00000000009b204c in run_poll_handlers_once (ctx=ctx@entry=0x6efea40, timeout=timeout@entry=0xffff7d7f7308) at util/aio-posix.c:521 #6 0x00000000009b2b64 in run_poll_handlers (ctx=ctx@entry=0x6efea40, max_ns=max_ns@entry=4000, timeout=timeout@entry=0xffff7d7f7308) at util/aio-posix.c:559 #7 0x00000000009b2ca0 in try_poll_mode (ctx=ctx@entry=0x6efea40, timeout=0xffff7d7f7308, timeout@entry=0xffff7d7f7348) at util/aio-posix.c:594 #8 0x00000000009b31b8 in aio_poll (ctx=0x6efea40, blocking=blocking@entry=true) at util/aio-posix.c:636 #9 0x00000000006973cc in iothread_run (opaque=0x6ebd800) at iothread.c:75 #10 0x00000000009b592c in qemu_thread_start (args=0x6efef60) at util/qemu-thread-posix.c:502 #11 0x0000ffff8057f8bc in start_thread () from /lib64/libpthread.so.0 #12 0x0000ffff804e5f8c in thread_start () from /lib64/libc.so.6 (gdb) p bus $1 = (SCSIBus *) 0x0 Signed-off-by: Zhengui li <lizhengui@huawei.com> Message-Id: <1563696502-7972-1-git-send-email-lizhengui@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <1563829520-17525-1-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: remove unused argument to virtio_scsi_common_realizePaolo Bonzini2019-07-191-2/+2
| | | | | | | | The argument is not used and passing it clutters error propagation in the callers. So, get rid of it. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster2019-06-121-0/+1
| | | | | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
* hw/scsi: Use the QOM BUS() macro to access BusState.qbusPhilippe Mathieu-Daudé2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | Rather than looking inside the definition of a BusState with "s->bus.qbus", use the QOM prefered style: "BUS(&s->bus)". This patch was generated using the following Coccinelle script: // Use BUS() macros to access BusState.qbus @use_bus_macro_to_access_qbus@ expression obj; identifier bus; @@ -&obj->bus.qbus +BUS(&obj->bus) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20190528164020.32250-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* scsi-disk: Use qdev_prop_drive_iothreadKevin Wolf2019-06-041-7/+8
| | | | | | | | | | | | | | This makes use of qdev_prop_drive_iothread for scsi-disk so that the disk can be attached to a node that is already in the target AioContext. We need to check that the HBA actually supports iothreads, otherwise scsi-disk must make sure that the node is already in the main AioContext. This changes the error message for conflicting iothread settings. Previously, virtio-scsi produced the error message, now it comes from blk_set_aio_context(). Update a test case accordingly. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Add Error to blk_set_aio_context()Kevin Wolf2019-06-041-3/+7
| | | | | | | | Add an Error parameter to blk_set_aio_context() and use bdrv_child_try_set_aio_context() internally to check whether all involved nodes can actually support the AioContext switch. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* virtio-scsi: Fix build with gcc 9Greg Kurz2019-03-111-1/+7
| | | | | | | | | | | | | | | | | | | | | Build fails with gcc 9: CC ppc64-softmmu/hw/scsi/virtio-scsi.o hw/scsi/virtio-scsi.c: In function ‘virtio_scsi_do_tmf’: hw/scsi/virtio-scsi.c:265:39: error: taking address of packed member of ‘struct virtio_scsi_ctrl_tmf_req’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 265 | virtio_tswap32s(VIRTIO_DEVICE(s), &req->req.tmf.subtype); | ^~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors All the fields in struct virtio_scsi_ctrl_tmf_req are naturally aligned, so we could in theory drop QEMU_PACKED. Unfortunately, the header file is imported from linux which already has the packed attribute. Trying to fix that in the update-linux-headers.sh script is likely to produce ugliness. Turn the call to virtio_tswap32s() into an assignment instead. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155137678223.44753.5438092367451176318.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qdev: pass an Object * to qbus_set_hotplug_handler()Michael Roth2019-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Certain devices types, like memory/CPU, are now being handled using a hotplug interface provided by a top-level MachineClass. Hotpluggable host bridges are another such device where it makes sense to use a machine-level hotplug handler. However, unlike those devices, host-bridges have a parent bus (the main system bus), and devices with a parent bus use a different mechanism for registering their hotplug handlers: qbus_set_hotplug_handler(). This interface currently expects a handler to be a subclass of DeviceClass, but this is not the case for MachineClass, which derives directly from ObjectClass. Internally, the interface only requires an ObjectClass, so expose that in qbus_set_hotplug_handler(). Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <154999589921.690774.3640149277362188566.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* virtio-scsi: Forbid devices with different iothreads sharing a blockdevAlberto Garcia2019-02-011-0/+7
| | | | | | | | This patch forbids attaching a disk to a SCSI device if its using a different AioContext. Test case included. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* virtio-scsi: Move BlockBackend back to the main AioContext on unplugAlberto Garcia2019-02-011-0/+6
| | | | | | | | | This fixes a crash when attaching a disk to a SCSI device using iothreads, then detaching it and reattaching it again. Test case included. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* call HotplugHandler->plug() as the last step in device realizationIgor Mammedov2018-10-191-10/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | When [2] was fixed it was agreed that adding and calling post_plug() callback after device_reset() was low risk approach to hotfix issue right before release. So it was merged instead of moving already existing plug() callback after device_reset() is called which would be more risky and require all plug() callbacks audit. Looking at the current plug() callbacks, it doesn't seem that moving plug() callback after device_reset() is breaking anything, so here goes agreed upon [3] proper fix which essentially reverts [1][2] and moves plug() callback after device_reset(). This way devices always comes to plug() stage, after it's been fully initialized (including being reset), which fixes race condition [2] without need for an extra post_plug() callback. 1. (25e897881 "qdev: add HotplugHandler->post_plug() callback") 2. (8449bcf94 "virtio-scsi: fix hotplug ->reset() vs event race") 3. https://www.mail-archive.com/qemu-devel@nongnu.org/msg549915.html Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1539696820-273275-1-git-send-email-imammedo@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Pierre Morel<pmorel@linux.ibm.com> Acked-by: Pierre Morel<pmorel@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: fix hotplug ->reset() vs event raceStefan Hajnoczi2018-07-161-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | There is a race condition during hotplug when iothread is used. It occurs because virtio-scsi may be processing command queues in the iothread while the monitor performs SCSI device hotplug. When a SCSI device is hotplugged the HotplugHandler->plug() callback is invoked and virtio-scsi emits a rescan event to the guest. If the guest submits a SCSI command at this point then it may be cancelled before hotplug completes. This happens because ->reset() is called by hw/core/qdev.c:device_set_realized() after HotplugHandler->plug() has been called and hw/scsi/scsi-disk.c:scsi_disk_reset() purges all requests. This patch uses the new HotplugHandler->post_plug() callback to emit the rescan event after ->reset(). This eliminates the race conditions where requests could be cancelled. Reported-by: l00284672 <lizhengui@huawei.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Fam Zheng <famz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20180716083732.3347-3-stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* scsi: move block/scsi.h to include/scsi/constants.hPaolo Bonzini2017-09-191-1/+1
| | | | | | | | | Complete the transition by renaming this header, which was shared by block/iscsi.c and the SCSI emulation code. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: Add virtqueue_size parameter allowing virtqueue size to be set.Richard W.M. Jones2017-09-191-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Linux switched to blk-mq as the default in Linux commit 5c279bd9e406 ("scsi: default to scsi-mq"), virtio-scsi LUNs consume about 10x as much guest kernel memory. This commit allows you to choose the virtqueue size for each virtio-scsi-pci controller like this: -device virtio-scsi-pci,id=scsi,virtqueue_size=16 The default is still 128 as before. Using smaller virtqueue_size allows many more disks to be added to small memory virtual machines. For a 1 vCPU, 500 MB, no swap VM I observed: With scsi-mq enabled (upstream kernel): 175 disks -"- ditto -"- virtqueue_size=64: 318 disks -"- ditto -"- virtqueue_size=16: 775 disks With scsi-mq disabled (kernel before 5c279bd9e406): 1755 disks Note that to have any effect, this requires a kernel patch: https://lkml.org/lkml/2017/8/10/689 Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20170810165255.20865-1-rjones@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: Convert to DEFINE_PROP_LINKFam Zheng2017-07-141-11/+2Star
| | | | | | Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170714021509.23681-8-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: finalize IOMMU supportJason Wang2017-07-041-1/+2
| | | | | | | | | | | | After converting to use DMA api for virtio devices, we should use dma_as instead of address_space_memory. Otherwise it won't work if IOMMU is enabled. Fixes: commit 8607f5c3072c ("virtio: convert to use DMA api") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <1499170866-9068-1-git-send-email-jasowang@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: Unset hotplug handler when unrealizeFam Zheng2017-06-061-0/+3
| | | | | | | | | | | | | | | | This matches the qbus_set_hotplug_handler in realize, and it releases the final reference to the embedded VirtIODevice so that it is properly finalized. A use-after-free is fixed with this patch, indirectly: virtio_device_instance_finalize wasn't called at hot-unplug, and the vdev->listener would be a dangling pointer in the global and the per address space listener list. See also RHBZ 1449031. Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170518102808.30046-1-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* scsi: Make errp the last parameter of virtio_scsi_common_realizeFam Zheng2017-04-241-4/+7
| | | | | | | | Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170421122710.15373-12-famz@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* virtio-scsi: Fix acquire/release in dataplane handlersFam Zheng2017-03-241-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | After the AioContext lock push down, there is a race between virtio_scsi_dataplane_start and those "assert(s->ctx && s->dataplane_started)", because the latter doesn't isn't wrapped in aio_context_acquire. Reproducer is simply booting a Fedora guest with an empty virtio-scsi-dataplane controller: qemu-system-x86_64 \ -drive if=none,id=root,format=raw,file=Fedora-Cloud-Base-25-1.3.x86_64.raw \ -device virtio-scsi \ -device scsi-disk,drive=root,bootindex=1 \ -object iothread,id=io \ -device virtio-scsi-pci,iothread=io \ -net user,hostfwd=tcp::10022-:22 -net nic,model=virtio -m 2048 \ --enable-kvm Fix this by moving acquire/release pairs from virtio_scsi_handle_*_vq to their callers - and wrap the broken assertions in. Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170317061447.16243-3-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: Make virtio_scsi_acquire/release publicFam Zheng2017-03-241-14/+0Star
| | | | | | | | | They will be used in virtio-scsi-dataplane.c as well, so move them to header. Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170317061447.16243-2-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Merge remote-tracking branch 'remotes/armbru/tags/pull-block-2017-02-21' ↵Peter Maydell2017-02-211-8/+0Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Changes to -drive without if= and with if=scsi # gpg: Signature made Tue 21 Feb 2017 12:22:35 GMT # gpg: using RSA key 0x3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-block-2017-02-21: hw/i386: Deprecate -drive if=scsi with PC machine types hw: Deprecate -drive if=scsi with non-onboard HBAs hw/scsi: Concentrate -drive if=scsi auto-create in one place hw: Drop superfluous special checks for orphaned -drive blockdev: Make orphaned -drive fatal blockdev: Improve message for orphaned -drive hw/arm/highbank: Default -drive to if=ide instead of if=scsi hw: Default -drive to if=none instead of scsi when scsi cannot work hw: Default -drive to if=none instead of ide when ide cannot work hw/arm/cubieboard hw/arm/xlnx-ep108: Fix units_per_default_bus hw: Default -drive to if=ide explicitly where it works Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * hw/scsi: Concentrate -drive if=scsi auto-create in one placeMarkus Armbruster2017-02-211-8/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic to create frontends for -drive if=scsi is in SCSI HBAs. For all other interface types, it's in machine initialization code. A few machine types create the SCSI HBAs necessary for that. That's also not done for other interface types. I'm going to deprecate these SCSI eccentricities. In preparation for that, create the frontends in main() instead of the SCSI HBAs, by calling new function scsi_legacy_handle_cmdline() there. Note that not all SCSI HBAs create frontends. Take care not to change that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1487161136-9018-2-git-send-email-armbru@redhat.com> Acked-By: Paolo Bonzini <pbonzini@redhat.com>
* | block: explicitly acquire aiocontext in callbacks that need itPaolo Bonzini2017-02-211-0/+7
|/ | | | | | | | | | | | This covers both file descriptor callbacks and polling callbacks, since they execute related code. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170213135235.12274-14-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* virtio: Report real progress in VQ aio poll handlerFam Zheng2017-02-171-3/+11
| | | | | | | | | | | | | | | | | | In virtio_queue_host_notifier_aio_poll, not all "!virtio_queue_empty()" cases are making true progress. Currently the offending one is virtio-scsi event queue, whose handler does nothing if no event is pending. As a result aio_poll() will spin on the "non-empty" VQ and take 100% host CPU. Fix this by reporting actual progress from virtio queue aio handlers. Reported-by: Ed Swierk <eswierk@skyportsystems.com> Signed-off-by: Fam Zheng <famz@redhat.com> Tested-by: Ed Swierk <eswierk@skyportsystems.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: convert to use DMA apiJason Wang2017-01-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | Currently, all virtio devices bypass IOMMU completely. This is because address_space_memory is assumed and used during DMA emulation. This patch converts the virtio core API to use DMA API. This idea is - introducing a new transport specific helper to query the dma address space. (only pci version is implemented). - query and use this address space during virtio device guest memory accessing when iommu platform (VIRTIO_F_IOMMU_PLATFORM) was enabled for this device. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Amit Shah <amit.shah@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: suppress virtqueue kick during processingStefan Hajnoczi2017-01-031-15/+21
| | | | | | | | | | The guest does not need to kick the virtqueue while we are processing it. This reduces the number of vmexits during periods of heavy I/O. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20161201192652.9509-9-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* virtio-scsi: introduce virtio_scsi_acquire/releasePaolo Bonzini2016-12-221-9/+18
| | | | | | | | | These will be used more as soon as the acquire/release is pushed down to the ioeventfd handlers. Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio: set ISR on dataplane notificationsPaolo Bonzini2016-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dataplane has been omitting forever the step of setting ISR when an interrupt is raised. This caused little breakage, because the specification actually says that ISR may not be updated in MSI mode. Some versions of the Windows drivers however didn't clear MSI mode correctly, and proceeded using polling mode (using ISR, not the used ring index!) for crashdump and hibernation. If it were just crashdump and hibernation it would not be a big deal, but recent releases of Windows do not really shut down, but rather log out and hibernate to make the next startup faster. Hence, this manifested as a more serious hang during shutdown with e.g. Windows 8.1 and virtio-win 1.8.0 RPMs. Newer versions fixed this, while older versions do not use MSI at all. The failure has always been there for virtio dataplane, but it became visible after commits 9ffe337 ("virtio-blk: always use dataplane path if ioeventfd is active", 2016-10-30) and ad07cd6 ("virtio-scsi: always use dataplane path if ioeventfd is active", 2016-10-30) made virtio-blk and virtio-scsi always use the dataplane code under KVM. The good news therefore is that it was not a bug in the patches---they were doing exactly what they were meant for, i.e. shake out remaining dataplane bugs. The fix is not hard, so it's worth arranging for the broken drivers. The virtio_should_notify+event_notifier_set pair that is common to virtio-blk and virtio-scsi dataplane is replaced with a new public function virtio_notify_irqfd that also sets ISR. The irqfd emulation code now need not set ISR anymore, so virtio_irq is removed. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Farhan Ali <alifm@linux.vnet.ibm.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: always use dataplane path if ioeventfd is activePaolo Bonzini2016-10-301-13/+11Star
| | | | | | | | | | | | | | | | | | | | | | | | | Override start_ioeventfd and stop_ioeventfd to start/stop the whole dataplane logic. This has some positive side effects: - no need anymore for virtio_add_queue_aio (i.e. a revert of commit 1c627137c10ee2dcf59e0383ade8a9abfa2d4355) - no need anymore to switch from generic ioeventfd handlers to dataplane It detects some errors better: $ qemu-system-x86_64 -object iothread,id=io \ -device virtio-scsi-pci,ioeventfd=off,iothread=io qemu-system-x86_64: -device virtio-scsi-pci,ioeventfd=off,iothread=io: ioeventfd is required for iothread while previously it would have started just fine. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio: cleanup VMSTATE_VIRTIO_DEVICEHalil Pasic2016-10-101-2/+0Star
| | | | | | | | | Now all the usages of the old version of VMSTATE_VIRTIO_DEVICE are gone, so we can get rid of the conditionals, and the old macro. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: convert VMSTATE_VIRTIO_DEVICEHalil Pasic2016-10-101-17/+11Star
| | | | | | | | Use the new VMSTATE_VIRTIO_DEVICE macro. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: handle virtio_scsi_set_config() errorGreg Kurz2016-10-101-2/+3
| | | | | | | | | | This error is caused by a buggy guest: let's switch the device to the broken state instead of terminating QEMU. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error()Greg Kurz2016-10-101-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The virtio_scsi_bad_req() function is called when a guest sends a request with missing or ill-sized headers. This generally happens when the virtio_scsi_parse_req() function returns an error. With this patch, virtio_scsi_bad_req() will mark the device as broken, detach the request from the virtqueue and free it, instead of forcing QEMU to exit. In nearly all locations where virtio_scsi_bad_req() is called, the only thing to do next is to return to the caller. The virtio_scsi_handle_cmd_req_prepare() function is an exception though. It is called in a loop by virtio_scsi_handle_cmd_vq() and passed requests freshly popped from a cmd virtqueue; virtio_scsi_handle_cmd_req_prepare() does some sanity checks on the request and returns a boolean flag to indicate whether the request should be queued or not. In the latter case, virtio_scsi_handle_cmd_req_prepare() has detected a non-fatal error and sent a response back to the guest. We have now a new condition to take into account: the device is broken and should stop all processing. The return value of virtio_scsi_handle_cmd_req_prepare() is hence changed to an int. A return value of zero means that the request should be queued. Other non-fatal error cases where the request shoudn't be queued return a negative errno (values are vaguely inspired by the error condition, but the only goal here is to discriminate the case we're interested in). And finally, if virtio_scsi_bad_req() was called, -EINVAL is returned. In this case, virtio_scsi_handle_cmd_vq() detaches and frees already queued requests, instead of submitting them. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* virtio-scsi: Don't abort when media is ejectedFam Zheng2016-09-141-6/+9
| | | | | | | | | With an ejected block backend, blk_get_aio_context() would return qemu_aio_context. In this case don't assert. Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1473848224-24809-3-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: Wrap in vmstateDr. David Alan Gilbert2016-07-211-15/+6Star
| | | | | | | | | | Forcibly convert it to a vmstate wrapper; proper conversion comes later. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-01-15 21:43:03 +0100