aboutsummaryrefslogtreecommitdiff
path: root/include/hw/virtio
AgeCommit message (Collapse)Author
2023-12-05hw/virtio: Add VirtioPCIDeviceTypeInfo::instance_finalize fieldPhilippe Mathieu-Daudé
The VirtioPCIDeviceTypeInfo structure, added in commit a4ee4c8baa ("virtio: Helper for registering virtio device types") got extended in commit 8ea90ee690 ("virtio: add class_size") with the @class_size field. Do similarly with the @instance_finalize field. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231121174051.63038-2-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 837053a7f491b445088eac647abe7f462c50f59a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-23include/hw/virtio/virtio-gpu: Fix virtio-gpu with blob on big endian hostsThomas Huth
Using "-device virtio-gpu,blob=true" currently does not work on big endian hosts (like s390x). The guest kernel prints an error message like: [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x10c) and the display stays black. When running QEMU with "-d guest_errors", it shows an error message like this: virtio_gpu_create_mapping_iov: nr_entries is too big (83886080 > 16384) which indicates that this value has not been properly byte-swapped. And indeed, the virtio_gpu_create_blob_bswap() function (that should swap the fields in the related structure) fails to swap some of the entries. After correctly swapping all missing values here, too, the virtio-gpu device is now also working with blob=true on s390x hosts. Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2230469 Message-Id: <20230815122007.928049-1-thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit d194362910138776e8abd6bb3c9fb3693254e95f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-07virtio-gpu: reset gfx resources in main threadMarc-André Lureau
Calling OpenGL from different threads can have bad consequences if not carefully reviewed. It's not generally supported. In my case, I was debugging a crash in glDeleteTextures from OPENGL32.DLL, where I asked qemu for gl=es, and thus ANGLE implementation was expected. libepoxy did resolution of the global pointer for glGenTexture to the GLES version from the main thread. But it resolved glDeleteTextures to the GL version, because it was done from a different thread without correct context. Oops. Let's stick to the main thread for GL calls by using a BH. Note: I didn't use atomics for reset_finished check, assuming the BQL will provide enough of sync, but I might be wrong. Acked-by: Dongwon Kim <dongwon.kim@intel.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230726173929.690601-3-marcandre.lureau@redhat.com>
2023-08-07virtio-gpu: free BHs, by implementing unrealizeMarc-André Lureau
Acked-by: Dongwon Kim <dongwon.kim@intel.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230726173929.690601-2-marcandre.lureau@redhat.com>
2023-08-03hw/virtio: Add a protection against duplicate vu_scmi_stop callsMilan Zamazal
The QEMU CI fails in virtio-scmi test occasionally. As reported by Thomas Huth, this happens most likely when the system is loaded and it fails with the following error: qemu-system-aarch64: ../../devel/qemu/hw/pci/msix.c:659: msix_unset_vector_notifiers: Assertion `dev->msix_vector_use_notifier && dev->msix_vector_release_notifier' failed. ../../devel/qemu/tests/qtest/libqtest.c:200: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) As discovered by Fabiano Rosas, the cause is a duplicate invocation of msix_unset_vector_notifiers via duplicate vu_scmi_stop calls: msix_unset_vector_notifiers virtio_pci_set_guest_notifiers vu_scmi_stop vu_scmi_disconnect ... qemu_chr_write_buffer msix_unset_vector_notifiers virtio_pci_set_guest_notifiers vu_scmi_stop vu_scmi_set_status ... qemu_cleanup While vu_scmi_stop calls are protected by vhost_dev_is_started() check, it's apparently not enough. vhost-user-blk and vhost-user-gpio use an extra protection, see f5b22d06fb (vhost: recheck dev state in the vhost_migration_log routine) for the motivation. Let's use the same in vhost-user-scmi, which fixes the failure above. Fixes: a5dab090e142 ("hw/virtio: Add boilerplate for vhost-user-scmi device") Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Message-Id: <20230720101037.2161450-1-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de>
2023-07-12virtio-mem: Prepare for device unplug supportDavid Hildenbrand
In many cases, blindly unplugging a virtio-mem device is problematic. We can only safely remove a device once: * The guest is not expecting to be able to read unplugged memory (unplugged-inaccessible == on) * The virtio-mem device does not have memory plugged (size == 0) * The virtio-mem device does not have outstanding requests to the VM to plug memory (requested-size == 0) So let's add a callback to the virtio-mem device class to check for that. We'll wire-up virtio-mem-pci next. Message-ID: <20230711153445.514112-7-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12virtio-md-pci: Support unplug requests for compatible devicesDavid Hildenbrand
Let's support unplug requests for virtio-md-pci devices that provide a unplug_request_check() callback. We'll wire that up for virtio-mem-pci next. Message-ID: <20230711153445.514112-6-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12pc: Factor out (un)plug handling of virtio-md-pci devicesDavid Hildenbrand
Let's factor out (un)plug handling, to be reused from arm/virt code. Provide stubs for the case that CONFIG_VIRTIO_MD is not selected because neither virtio-mem nor virtio-pmem is enabled. While this cannot currently happen for x86, it will be possible for arm/virt. Message-ID: <20230711153445.514112-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12virtio-md-pci: New parent type for virtio-mem-pci and virtio-pmem-pciDavid Hildenbrand
Let's add a new abstract "virtio memory device" type, and use it as parent class of virtio-mem-pci and virtio-pmem-pci. Message-ID: <20230711153445.514112-2-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-10include/hw/virtio: document some more usage of notifiersAlex Bennée
Lets document some more of the core VirtIODevice structure. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-7-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10include/hw/virtio: add kerneldoc for virtio_initAlex Bennée
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-6-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10include/hw/virtio: document virtio_notify_configAlex Bennée
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-5-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10virtio-iommu: Fix 64kB host page size VFIO device assignmentEric Auger
When running on a 64kB page size host and protecting a VFIO device with the virtio-iommu, qemu crashes with this kind of message: qemu-kvm: virtio-iommu page mask 0xfffffffffffff000 is incompatible with mask 0x20010000 qemu: hardware error: vfio: DMA mapping failed, unable to continue This is due to the fact the IOMMU MR corresponding to the VFIO device is enabled very late on domain attach, after the machine init. The device reports a minimal 64kB page size but it is too late to be applied. virtio_iommu_set_page_size_mask() fails and this causes vfio_listener_region_add() to end up with hw_error(); To work around this issue, we transiently enable the IOMMU MR on machine init to collect the page size requirements and then restore the bypass state. Fixes: 90519b9053 ("virtio-iommu: Add bypass mode support to assigned device") Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20230705165118.28194-2-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Tested-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
2023-07-10hw/virtio: Add boilerplate for vhost-user-scmi deviceMilan Zamazal
This creates the QEMU side of the vhost-user-scmi device which connects to the remote daemon. It is based on code of similar vhost-user devices. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Message-Id: <20230628100524.342666-2-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10virtio-gpu: refactor generate_edid function to virtio_gpu_baseErico Nunes
This functionality can be shared with upcoming use in vhost-user-gpu, so move it to the shared file to avoid duplicating it. Signed-off-by: Erico Nunes <ernunes@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230626164708.1163239-2-ernunes@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10vhost: register and change IOMMU flag depending on Device-TLB stateViktor Prutyanov
The guest can disable or never enable Device-TLB. In these cases, it can't be used even if enabled in QEMU. So, check Device-TLB state before registering IOMMU notifier and select unmap flag depending on that. Also, implement a way to change IOMMU notifier flag if Device-TLB state is changed. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2001312 Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230626091258.24453-2-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-27virtio-gpu/win32: allocate shareable 2d resources/imagesMarc-André Lureau
Allocate pixman bits for scanouts with qemu_win32_map_alloc() so we can set a shareable handle on the associated display surface. Note: when bits are provided to pixman_image_create_bits(), you must also give the rowstride (the argument is ignored when bits is NULL) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230606115658.677673-11-marcandre.lureau@redhat.com>
2023-06-26vhost-user: fully use new backend/frontend namingManos Pitsidianakis
Slave/master nomenclature was replaced with backend/frontend in commit 1fc19b65279a ("vhost-user: Adopt new backend naming") This patch replaces all remaining uses of master and slave in the codebase. Signed-off-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20230613080849.2115347-1-manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2023-06-26virtio-net: expose virtio_net_supported_guest_offloads()Hawkins Jiawei
To support restoring offloads state in vdpa, it is necessary to expose the function virtio_net_supported_guest_offloads(). According to VirtIO standard, "Upon feature negotiation corresponding offload gets enabled to preserve backward compatibility.". Therefore, QEMU uses this function to get the device supported offloads. This allows QEMU to know the device's defaults and skip the control message sending if these defaults align with the driver's configuration. Note that the device's defaults can mismatch the driver's configuration only at live migration. Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Message-Id: <43679506f3f039a7aa2bdd5b49785107b5dfd7d4.1685704856.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Tested-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-26include/hw/virtio: make some VirtIODevice constHawkins Jiawei
The VirtIODevice structure is not modified in virtio_vdev_has_feature(). Therefore, make it const to allow this function to accept const variables. Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Reviewed-by: Eugenio Pérez Martin <eperezma@redhat.com> Message-Id: <16c0561b921310a32c240a4fb6e8cee3ffee16fe.1685704856.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Tested-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-28virtio-input: add a virtio-mulitouch deviceSergio Lopez
Add a virtio-multitouch device to the family of devices emulated by virtio-input implementing the Multi-touch protocol as descripted here: https://www.kernel.org/doc/html/latest/input/multi-touch-protocol.html?highlight=multi+touch This patch just add the device itself, without connecting it to any backends. The following patches will add a PCI-based multitouch device, some helpers in "ui" and will enable the GTK3 backend to transpose multi-touch events from the host to the guest. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230526112925.38794-4-slp@redhat.com>
2023-05-19virtio-pci: add handling of PCI ATS and Device-TLB enable/disableViktor Prutyanov
According to PCIe Address Translation Services specification 5.1.3., ATS Control Register has Enable bit to enable/disable ATS. Guest may enable/disable PCI ATS and, accordingly, Device-TLB for the VirtIO PCI device. So, raise/lower a flag and call a trigger function to pass this event to a device implementation. Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Message-Id: <20230512135122.70403-2-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19vhost-vdpa: Add support for vIOMMU.Cindy Lu
1. The vIOMMU support will make vDPA can work in IOMMU mode. This will fix security issues while using the no-IOMMU mode. To support this feature we need to add new functions for IOMMU MR adds and deletes. Also since the SVQ does not support vIOMMU yet, add the check for IOMMU in vhost_vdpa_dev_start, if the SVQ and IOMMU enable at the same time the function will return fail. 2. Skip the iova_max check vhost_vdpa_listener_skipped_section(). While MR is IOMMU, move this check to vhost_vdpa_iommu_map_notify() Verified in vp_vdpa and vdpa_sim_net driver Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20230510054631.2951812-5-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19vhost: expose function vhost_dev_has_iommu()Cindy Lu
To support vIOMMU in vdpa, need to exposed the function vhost_dev_has_iommu, vdpa will use this function to check if vIOMMU enable. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20230510054631.2951812-2-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-04-21virtio: refresh vring region cache after updating a virtqueue sizeCarlos López
When a virtqueue size is changed by the guest via virtio_queue_set_num(), its region cache is not automatically updated. If the size was increased, this could lead to accessing the cache out of bounds. For example, in vring_get_used_event(): static inline uint16_t vring_get_used_event(VirtQueue *vq) { return vring_avail_ring(vq, vq->vring.num); } static inline uint16_t vring_avail_ring(VirtQueue *vq, int i) { VRingMemoryRegionCaches *caches = vring_get_region_caches(vq); hwaddr pa = offsetof(VRingAvail, ring[i]); if (!caches) { return 0; } return virtio_lduw_phys_cached(vq->vdev, &caches->avail, pa); } vq->vring.num will be greater than caches->avail.len, which will trigger a failed assertion down the call path of virtio_lduw_phys_cached(). Fix this by calling virtio_init_region_cache() after virtio_queue_set_num() if we are not already calling virtio_queue_set_rings(). In the legacy path this is already done by virtio_queue_update_rings(). Signed-off-by: Carlos López <clopez@suse.de> Message-Id: <20230317002749.27379-1-clopez@suse.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-20replace TABs with spacesYeqi Fu
Bring the files in line with the QEMU coding style, with spaces for indentation. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/378 Signed-off-by: Yeqi Fu <fufuyqqqqqq@gmail.com> Message-Id: <20230315032649.57568-1-fufuyqqqqqq@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-03-07vdpa net: block migration if the device has CVQEugenio Pérez
Devices with CVQ need to migrate state beyond vq state. Leaving this to future series. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-11-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: move vhost reset after get vring baseEugenio Pérez
The function vhost.c:vhost_dev_stop calls vhost operation vhost_dev_start(false). In the case of vdpa it totally reset and wipes the device, making the fetching of the vring base (virtqueue state) totally useless. The kernel backend does not use vhost_dev_start vhost op callback, but vhost-user do. A patch to make vhost_user_dev_start more similar to vdpa is desirable, but it can be added on top. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-8-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: add vhost_vdpa->suspended parameterEugenio Pérez
This allows vhost_vdpa to track if it is safe to get the vring base from the device or not. If it is not, vhost can fall back to fetch idx from the guest buffer again. No functional change intended in this patch, later patches will use this field. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-6-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02vhost-user-gpio: Configure vhost_dev when connectingAkihiko Odaki
vhost_dev_cleanup(), called from vu_gpio_disconnect(), clears vhost_dev so vhost-user-gpio must set the members of vhost_dev each time connecting. do_vhost_user_cleanup() should also acquire the pointer to vqs directly from VHostUserGPIO instead of referring to vhost_dev as it can be called after vhost_dev_cleanup(). Fixes: 27ba7b027f ("hw/virtio: add boilerplate for vhost-user-gpio device") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230130140320.77999-1-akihiko.odaki@daynix.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-02-23virtio-scsi: reset SCSI devices from main loop threadStefan Hajnoczi
When an IOThread is configured, the ctrl virtqueue is processed in the IOThread. TMFs that reset SCSI devices are currently called directly from the IOThread and trigger an assertion failure in blk_drain() from the following call stack: virtio_scsi_handle_ctrl_req -> virtio_scsi_do_tmf -> device_code_reset -> scsi_disk_reset -> scsi_device_purge_requests -> blk_drain ../block/block-backend.c:1780: void blk_drain(BlockBackend *): Assertion `qemu_in_main_thread()' failed. The blk_drain() function is not designed to be called from an IOThread because it needs the Big QEMU Lock (BQL). This patch defers TMFs that reset SCSI devices to a Bottom Half (BH) that runs in the main loop thread under the BQL. This way it's safe to call blk_drain() and the assertion failure is avoided. Introduce s->tmf_bh_list for tracking TMF requests that have been deferred to the BH. When the BH runs it will grab the entire list and process all requests. Care must be taken to clear the list when the virtio-scsi device is reset or unrealized. Otherwise deferred TMF requests could execute later and lead to use-after-free or other undefined behavior. The s->resetting counter that's used by TMFs that reset SCSI devices is accessed from multiple threads. This patch makes that explicit by using atomic accessor functions. With this patch applied the counter is only modified by the main loop thread under the BQL but can be read by any thread. Reported-by: Qing Wang <qinwang@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230221212218.1378734-4-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-02-06virtio-mem: Migrate immutable properties earlyDavid Hildenbrand
The bitmap and the size are immutable while migration is active: see virtio_mem_is_busy(). We can migrate this information early, before migrating any actual RAM content. Further, all information we need for sanity checks is immutable as well. Having this information in place early will, for example, allow for properly preallocating memory before touching these memory locations during RAM migration: this way, we can make sure that all memory was actually preallocated and that any user errors (e.g., insufficient hugetlb pages) can be handled gracefully. In contrast, usable_region_size and requested_size can theoretically still be modified on the source while the VM is running. Keep migrating these properties the usual, late, way. Use a new device property to keep behavior of compat machines unmodified. Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>S Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2023-01-23virtio-blk: simplify virtio_blk_dma_restart_cb()Stefan Hajnoczi
virtio_blk_dma_restart_cb() is tricky because the BH must deal with virtio_blk_data_plane_start()/virtio_blk_data_plane_stop() being called. There are two issues with the code: 1. virtio_blk_realize() should use qdev_add_vm_change_state_handler() instead of qemu_add_vm_change_state_handler(). This ensures the ordering with virtio_init()'s vm change state handler that calls virtio_blk_data_plane_start()/virtio_blk_data_plane_stop() is well-defined. Then blk's AioContext is guaranteed to be up-to-date in virtio_blk_dma_restart_cb() and it's no longer necessary to have a special case for virtio_blk_data_plane_start(). 2. Only blk_drain() waits for virtio_blk_dma_restart_cb()'s blk_inc_in_flight() to be decremented. The bdrv_drain() family of functions do not wait for BlockBackend's in_flight counter to reach zero. virtio_blk_data_plane_stop() relies on blk_set_aio_context()'s implicit drain, but that's a bdrv_drain() and not a blk_drain(). Note that virtio_blk_reset() already correctly relies on blk_drain(). If virtio_blk_data_plane_stop() switches to blk_drain() then we can properly wait for pending virtio_blk_dma_restart_bh() calls. Once these issues are taken care of the code becomes simpler. This change is in preparation for multiple IOThreads in virtio-blk where we need to clean up the multi-threading behavior. I ran the reproducer from commit 49b44549ace7 ("virtio-blk: On restart, process queued requests in the proper context") to check that there is no regression. Cc: Sergio Lopez <slp@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Emanuele Giuseppe Esposito <eesposit@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-id: 20221102182337.252202-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-01-08vdpa-dev: get iova range explicitlyLongpeng
In commit a585fad26b ("vdpa: request iova_range only once") we remove GET_IOVA_RANGE form vhost_vdpa_init, the generic vdpa device will start without iova_range populated, so the device won't work. Let's call GET_IOVA_RANGE ioctl explicitly. Fixes: a585fad26b2e6ccc ("vdpa: request iova_range only once") Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221224114848.3062-2-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2023-01-08include: Include headers where neededMarkus Armbruster
A number of headers neglect to include everything they need. They compile only if the headers they need are already included from elsewhere. Fix that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221222120813.727830-3-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08include/hw/virtio: Break inclusion loopMarkus Armbruster
hw/virtio/virtio.h and hw/virtio/vhost.h include each other. The former doesn't actually need the latter, so drop that inclusion to break the loop. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20221222120813.727830-2-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com>
2023-01-08include/hw/pci: Break inclusion loop pci_bridge.h and cxl.hMarkus Armbruster
hw/pci/pci_bridge.h and hw/cxl/cxl.h include each other. Fortunately, breaking the loop is merely a matter of deleting unnecessary includes from headers, and adding them back in places where they are now missing. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-2-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08virtio-pci: add support for configure interruptCindy Lu
Add process to handle the configure interrupt, The function's logic is the same with vq interrupt.Add extra process to check the configure interrupt Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-11-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08vhost: add support for configure interruptCindy Lu
Add functions to support configure interrupt. The configure interrupt process will start in vhost_dev_start and stop in vhost_dev_stop. Also add the functions to support vhost_config_pending and vhost_config_mask. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-8-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08virtio: add support for configure interruptCindy Lu
Add the functions to support the configure interrupt in virtio The function virtio_config_guest_notifier_read will notify the guest if there is an configure interrupt. The function virtio_config_set_guest_notifier_fd_handler is to set the fd hander for the notifier Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-7-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08vhost: introduce new VhostOps vhost_set_config_callCindy Lu
This patch introduces new VhostOps vhost_set_config_call. This function allows the qemu to set the config event fd to kernel driver. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-5-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08virtio: introduce macro VIRTIO_CONFIG_IRQ_IDXCindy Lu
To support configure interrupt for vhost-vdpa Introduce VIRTIO_CONFIG_IRQ_IDX -1 as configure interrupt's queue index, Then we can reuse the functions guest_notifier_mask and guest_notifier_pending. Add the check of queue index in these drivers, if the driver does not support configure interrupt, the function will just return Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-2-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21include/hw: attempt to document VirtIO feature variablesAlex Bennée
We have a bunch of variables associated with the device and the vhost backend which are used inconsistently throughout the code base. Lets start trying to bring some order by agreeing what each variable is for. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Stefano Garzarella <sgarzare@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Stefan Hajnoczi <stefanha@gmail.com> Message-Id: <20221123152134.179929-2-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: add shadow_data to vhost_vdpaEugenio Pérez
The memory listener that thells the device how to convert GPA to qemu's va is registered against CVQ vhost_vdpa. memory listener translations are always ASID 0, CVQ ones are ASID 1 if supported. Let's tell the listener if it needs to register them on iova tree or not. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-12-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: add asid parameter to vhost_vdpa_dma_map/unmapEugenio Pérez
So the caller can choose which ASID is destined. No need to update the batch functions as they will always be called from memory listener updates at the moment. Memory listener updates will always update ASID 0, as it's the passthrough ASID. All vhost devices's ASID are 0 at this moment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-10-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: add vdpa-dev supportLongpeng
Supports vdpa-dev, we can use the deivce directly: -M microvm -m 512m -smp 2 -kernel ... -initrd ... -device \ vhost-vdpa-device,vhostdev=/dev/vhost-vdpa-x Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221215134944.2809-3-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21virtio: get class_id and pci device id by the virtio idLongpeng
Add helpers to get the "Transitional PCI Device ID" and "class_id" of the device specified by the "Virtio Device ID". These helpers will be used to build the generic vDPA device later. Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221215134944.2809-2-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-01include/hw: VM state takes precedence in virtio_device_should_startAlex Bennée
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 <alex.bennee@linaro.org> Tested-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20221130112439.2527228-6-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-01hw/virtio: generalise CHR_EVENT_CLOSED handlingAlex Bennée
..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 <alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20221130112439.2527228-5-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-01hw/virtio: add started_vu status field to vhost-user-gpioAlex Bennée
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 <alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20221130112439.2527228-4-alex.bennee@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 05:00:41 +0000