aboutsummaryrefslogtreecommitdiff
path: root/hw/virtio
AgeCommit message (Collapse)Author
2023-03-07virtio: fix reachable assertion due to stale value of cached region sizeCarlos López
In virtqueue_{split,packed}_get_avail_bytes() descriptors are read in a loop via MemoryRegionCache regions and calls to vring_{split,packed}_desc_read() - these take a region cache and the index of the descriptor to be read. For direct descriptors we use a cache provided by the caller, whose size matches that of the virtqueue vring. We limit the number of descriptors we can read by the size of that vring: max = vq->vring.num; ... MemoryRegionCache *desc_cache = &caches->desc; For indirect descriptors, we initialize a new cache and limit the number of descriptors by the size of the intermediate descriptor: len = address_space_cache_init(&indirect_desc_cache, vdev->dma_as, desc.addr, desc.len, false); desc_cache = &indirect_desc_cache; ... max = desc.len / sizeof(VRingDesc); However, the first initialization of `max` is done outside the loop where we process guest descriptors, while the second one is done inside. This means that a sequence of an indirect descriptor followed by a direct one will leave a stale value in `max`. If the second descriptor's `next` field is smaller than the stale value, but greater than the size of the virtqueue ring (and thus the cached region), a failed assertion will be triggered in address_space_read_cached() down the call chain. Fix this by initializing `max` inside the loop in both functions. Fixes: 9796d0ac8fb0 ("virtio: use address_space_map/unmap to access descriptors") Signed-off-by: Carlos López <clopez@suse.de> Message-Id: <20230302100358.3613-1-clopez@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07hw/virtio/vhost-user: avoid using unitialized errpAlbert Esteve
During protocol negotiation, when we the QEMU stub does not support a backend with F_CONFIG, it throws a warning and supresses the VHOST_USER_PROTOCOL_F_CONFIG bit. However, the warning uses warn_reportf_err macro and passes an unitialized errp pointer. However, the macro tries to edit the 'msg' member of the unitialized Error and segfaults. Instead, just use warn_report, which prints a warning message directly to the output. Fixes: 5653493 ("hw/virtio/vhost-user: don't suppress F_CONFIG when supported") Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20230302121719.9390-1-aesteve@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07vdpa: return VHOST_F_LOG_ALL in vhost-vdpa devicesEugenio Pérez
vhost-vdpa devices can return this feature now that blockers have been set in case some features are not met. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-15-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: block migration if SVQ does not admit a featureEugenio Pérez
Next patches enable devices to be migrated even if vdpa netdev has not been started with x-svq. However, not all devices are migratable, so we need to block migration if we detect that. Block migration if we detect the device expose a feature SVQ does not know how to work with. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-13-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 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: disable RAM block discard only for the first deviceEugenio Pérez
Although it does not make a big difference, its more correct and simplifies the cleanup path in subsequent patches. Move ram_block_discard_disable(false) call to the top of vhost_vdpa_cleanup because: * We cannot use vhost_vdpa_first_dev after dev->opaque = NULL assignment. * Improve the stack order in cleanup: since it is the last action taken in init, it should be the first at cleanup. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-10-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_suspendEugenio Pérez
The function vhost.c:vhost_dev_stop fetches the vring base so the vq state can be migrated to other devices. However, this is unreliable in vdpa, since we didn't signal the device to suspend the queues, making the value fetched useless. Suspend the device if possible before fetching first and subsequent vring bases. Moreover, vdpa totally reset and wipes the device at the last device before fetch its vrings base, making that operation useless in the last device. This will be fixed in later patches of this series. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-7-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-07vdpa: rewind at get_base, not set_baseEugenio Pérez
At this moment it is only possible to migrate to a vdpa device running with x-svq=on. As a protective measure, the rewind of the inflight descriptors was done at the destination. That way if the source sent a virtqueue with inuse descriptors they are always discarded. Since this series allows to migrate also to passthrough devices with no SVQ, the right thing to do is to rewind at the source so the base of vrings are correct. Support for inflight descriptors may be added in the future. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-5-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: Negotiate _F_SUSPEND featureEugenio Pérez
This is needed for qemu to know it can suspend the device to retrieve its status and enable SVQ with it, so all the process is transparent to the guest. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230303172445.1089785-4-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: Remember last call fd setEugenio Pérez
As SVQ can be enabled dynamically at any time, it needs to store call fd always. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230303172445.1089785-3-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-07cryptodev: Use CryptoDevBackendOpInfo for operationzhenwei pi
Move queue_index, CryptoDevCompletionFunc and opaque into struct CryptoDevBackendOpInfo, then cryptodev_backend_crypto_operation() needs an argument CryptoDevBackendOpInfo *op_info only. And remove VirtIOCryptoReq from cryptodev. It's also possible to hide VirtIOCryptoReq into virtio-crypto.c in the next step. (In theory, VirtIOCryptoReq is a private structure used by virtio-crypto only) Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-9-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07cryptodev: Introduce server type in QAPIzhenwei pi
Introduce cryptodev service type in cryptodev.json, then apply this to related codes. Now we can remove VIRTIO_CRYPTO_SERVICE_xxx dependence from QEMU cryptodev. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-5-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07cryptodev: Introduce cryptodev alg type in QAPIzhenwei pi
Introduce cryptodev alg type in cryptodev.json, then apply this to related codes, and drop 'enum CryptoDevBackendAlgType'. There are two options: 1, { 'enum': 'QCryptodevBackendAlgType', 'prefix': 'CRYPTODEV_BACKEND_ALG', 'data': ['sym', 'asym']} Then we can keep 'CRYPTODEV_BACKEND_ALG_SYM' and avoid lots of changes. 2, changes in this patch(with prefix 'QCRYPTODEV_BACKEND_ALG'). To avoid breaking the rule of QAPI, use 2 here. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-4-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02vhost: avoid a potential use of an uninitialized variable in vhost_svq_poll()Carlos López
In vhost_svq_poll(), if vhost_svq_get_buf() fails due to a device providing invalid descriptors, len is left uninitialized and returned to the caller, potentally leaking stack data or causing undefined behavior. Fix this by initializing len to 0. Found with GCC 13 and -fanalyzer (abridged): ../hw/virtio/vhost-shadow-virtqueue.c: In function ‘vhost_svq_poll’: ../hw/virtio/vhost-shadow-virtqueue.c:538:12: warning: use of uninitialized value ‘len’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 538 | return len; | ^~~ ‘vhost_svq_poll’: events 1-4 | | 522 | size_t vhost_svq_poll(VhostShadowVirtqueue *svq) | | ^~~~~~~~~~~~~~ | | | | | (1) entry to ‘vhost_svq_poll’ |...... | 525 | uint32_t len; | | ~~~ | | | | | (2) region created on stack here | | (3) capacity: 4 bytes |...... | 528 | if (vhost_svq_more_used(svq)) { | | ~ | | | | | (4) inlined call to ‘vhost_svq_more_used’ from ‘vhost_svq_poll’ (...) | 528 | if (vhost_svq_more_used(svq)) { | | ^~~~~~~~~~~~~~~~~~~~~~~~~ | | || | | |(8) ...to here | | (7) following ‘true’ branch... |...... | 537 | vhost_svq_get_buf(svq, &len); | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (9) calling ‘vhost_svq_get_buf’ from ‘vhost_svq_poll’ | +--> ‘vhost_svq_get_buf’: events 10-11 | | 416 | static VirtQueueElement *vhost_svq_get_buf(VhostShadowVirtqueue *svq, | | ^~~~~~~~~~~~~~~~~ | | | | | (10) entry to ‘vhost_svq_get_buf’ |...... | 423 | if (!vhost_svq_more_used(svq)) { | | ~ | | | | | (11) inlined call to ‘vhost_svq_more_used’ from ‘vhost_svq_get_buf’ | (...) | ‘vhost_svq_get_buf’: event 14 | | 423 | if (!vhost_svq_more_used(svq)) { | | ^ | | | | | (14) following ‘false’ branch... | ‘vhost_svq_get_buf’: event 15 | |cc1: | (15): ...to here | <------+ | ‘vhost_svq_poll’: events 16-17 | | 537 | vhost_svq_get_buf(svq, &len); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (16) returning to ‘vhost_svq_poll’ from ‘vhost_svq_get_buf’ | 538 | return len; | | ~~~ | | | | | (17) use of uninitialized value ‘len’ here Note by Laurent Vivier <lvivier@redhat.com>: The return value is only used to detect an error: vhost_svq_poll vhost_vdpa_net_cvq_add vhost_vdpa_net_load_cmd vhost_vdpa_net_load_mac -> a negative return is only used to detect error vhost_vdpa_net_load_mq -> a negative return is only used to detect error vhost_vdpa_net_handle_ctrl_avail -> a negative return is only used to detect error Fixes: d368c0b052ad ("vhost: Do not depend on !NULL VirtQueueElement on vhost_svq_flush") Signed-off-by: Carlos López <clopez@suse.de> Message-Id: <20230213085747.19956-1-clopez@suse.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02vdpa: stop all svq on device deletionEugenio Pérez
Not stopping them leave the device in a bad state when virtio-net fronted device is unplugged with device_del monitor command. This is not triggable in regular poweroff or qemu forces shutdown because cleanup is called right after vhost_vdpa_dev_start(false). But devices hot unplug does not call vdpa device cleanups. This lead to all the vhost_vdpa devices without stop the SVQ but the last. Fix it and clean the code, making it symmetric with vhost_vdpa_svqs_start. Fixes: dff4426fa656 ("vhost: Add Shadow VirtQueue kick forwarding capabilities") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230209170004.899472-1-eperezma@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2023-03-02vhost-user: Adopt new backend namingMaxime Coquelin
The Vhost-user specification changed feature and request naming from _SLAVE_ to _BACKEND_. This patch adopts the new naming convention. Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20230208203259.381326-4-maxime.coquelin@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02vhost-user-rng: Back up vqs before cleaning up vhost_devAkihiko Odaki
vhost_dev_cleanup() clears vhost_dev so back up its vqs member to free the memory pointed by the member. Fixes: 821d28b88f ("vhost-user-rng: Add vhost-user-rng implementation") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230130140516.78078-1-akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02vhost-user-i2c: Back up vqs before cleaning up vhost_devAkihiko Odaki
vhost_dev_cleanup() clears vhost_dev so back up its vqs member to free the memory pointed by the member. Fixes: 7221d3b634 ("hw/virtio: add boilerplate for vhost-user-i2c device") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230130140435.78049-1-akihiko.odaki@daynix.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-09vhost-user-fs: Back up vqs before cleaning up vhost_devAkihiko Odaki
vhost_dev_cleanup() clears vhost_dev so back up its vqs member to free the memory pointed by the member. Fixes: 98fc1ada4c ("virtio: add vhost-user-fs base device") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230130140225.77964-1-akihiko.odaki@daynix.com>
2023-02-06virtio-mem: Proper support for preallocation with migrationDavid Hildenbrand
Ordinary memory preallocation runs when QEMU starts up and creates the memory backends, before processing the incoming migration stream. With virtio-mem, we don't know which memory blocks to preallocate before migration started. Now that we migrate the virtio-mem bitmap early, before migrating any RAM content, we can safely preallocate memory for all plugged memory blocks before migrating any RAM content. This is especially relevant for the following cases: (1) User errors With hugetlb/files, if we don't have sufficient backend memory available on the migration destination, we'll crash QEMU (SIGBUS) during RAM migration when running out of backend memory. Preallocating memory before actual RAM migration allows for failing gracefully and informing the user about the setup problem. (2) Excluded memory ranges during migration For example, virtio-balloon free page hinting will exclude some pages from getting migrated. In that case, we won't crash during RAM migration, but later, when running the VM on the destination, which is bad. To fix this for new QEMU machines that migrate the bitmap early, preallocate the memory early, before any RAM migration. Warn with old QEMU machines. Getting postcopy right is a bit tricky, but we essentially now implement the same (problematic) preallocation logic as ordinary preallocation: preallocate memory early and discard it again before precopy starts. During ordinary preallocation, discarding of RAM happens when postcopy is advised. As the state (bitmap) is loaded after postcopy was advised but before postcopy starts listening, we have to discard memory we preallocated immediately again ourselves. Note that nothing (not even hugetlb reservations) guarantees for postcopy that backend memory (especially, hugetlb pages) are still free after they were freed ones while discarding RAM. Still, allocating that memory at least once helps catching some basic setup problems. Before this change, trying to restore a VM when insufficient hugetlb pages are around results in the process crashing to to a "Bus error" (SIGBUS). With this change, QEMU fails gracefully: qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad address qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:03.0/virtio-mem-device-early' qemu-system-x86_64: load of migration failed: Cannot allocate memory And we can even introspect the early migration data, including the bitmap: $ ./scripts/analyze-migration.py -f STATEFILE { "ram (2)": { "section sizes": { "0000:00:03.0/mem0": "0x0000000780000000", "0000:00:04.0/mem1": "0x0000000780000000", "pc.ram": "0x0000000100000000", "/rom@etc/acpi/tables": "0x0000000000020000", "pc.bios": "0x0000000000040000", "0000:00:02.0/e1000.rom": "0x0000000000040000", "pc.rom": "0x0000000000020000", "/rom@etc/table-loader": "0x0000000000001000", "/rom@etc/acpi/rsdp": "0x0000000000001000" } }, "0000:00:03.0/virtio-mem-device-early (51)": { "tmp": "00 00 00 01 40 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00", "size": "0x0000000040000000", "bitmap": "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [...] }, "0000:00:04.0/virtio-mem-device-early (53)": { "tmp": "00 00 00 08 c0 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00", "size": "0x00000001fa400000", "bitmap": "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [...] }, [...] Reported-by: Jing Qi <jinqi@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> 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-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-02-06virtio-mem: Fail if a memory backend with "prealloc=on" is specifiedDavid Hildenbrand
"prealloc=on" for the memory backend does not work as expected, as virtio-mem will simply discard all preallocated memory immediately again. In the best case, it's an expensive NOP. In the worst case, it's an unexpected allocation error. Instead, "prealloc=on" should be specified for the virtio-mem device only, such that virtio-mem will try preallocating memory before plugging memory dynamically to the guest. Fail if such a memory backend is provided. Tested-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> 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-02-04virtio: Move HMP commands from monitor/ to hw/virtio/Markus Armbruster
This moves these commands from MAINTAINERS section "Human Monitor (HMP)" to "virtio". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230124121946.1139465-20-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-28Revert "vhost-user: Introduce nested event loop in vhost_user_read()"Greg Kurz
This reverts commit a7f523c7d114d445c5d83aecdba3efc038e5a692. The nested event loop is broken by design. It's only user was removed. Drop the code as well so that nobody ever tries to use it again. I had to fix a couple of trivial conflicts around return values because of 025faa872bcf ("vhost-user: stick to -errno error return convention"). Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20230119172424.478268-3-groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2023-01-28Revert "vhost-user: Monitor slave channel in vhost_user_read()"Greg Kurz
This reverts commit db8a3772e300c1a656331a92da0785d81667dc81. Motivation : this is breaking vhost-user with DPDK as reported in [0]. Received unexpected msg type. Expected 22 received 40 Fail to update device iotlb Received unexpected msg type. Expected 40 received 22 Received unexpected msg type. Expected 22 received 11 Fail to update device iotlb Received unexpected msg type. Expected 11 received 22 vhost VQ 1 ring restore failed: -71: Protocol error (71) Received unexpected msg type. Expected 22 received 11 Fail to update device iotlb Received unexpected msg type. Expected 11 received 22 vhost VQ 0 ring restore failed: -71: Protocol error (71) unable to start vhost net: 71: falling back on userspace virtio The failing sequence that leads to the first error is : - QEMU sends a VHOST_USER_GET_STATUS (40) request to DPDK on the master socket - QEMU starts a nested event loop in order to wait for the VHOST_USER_GET_STATUS response and to be able to process messages from the slave channel - DPDK sends a couple of legitimate IOTLB miss messages on the slave channel - QEMU processes each IOTLB request and sends VHOST_USER_IOTLB_MSG (22) updates on the master socket - QEMU assumes to receive a response for the latest VHOST_USER_IOTLB_MSG but it gets the response for the VHOST_USER_GET_STATUS instead The subsequent errors have the same root cause : the nested event loop breaks the order by design. It lures QEMU to expect responses to the latest message sent on the master socket to arrive first. Since this was only needed for DAX enablement which is still not merged upstream, just drop the code for now. A working solution will have to be merged later on. Likely protect the master socket with a mutex and service the slave channel with a separate thread, as discussed with Maxime in the mail thread below. [0] https://lore.kernel.org/qemu-devel/43145ede-89dc-280e-b953-6a2b436de395@redhat.com/ Reported-by: Yanghang Liu <yanghliu@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2155173 Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20230119172424.478268-2-groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2023-01-28hw: Use TYPE_PCI_BUS definition where appropriatePhilippe Mathieu-Daudé
Use the proper QOM type definition instead of magic string. This also helps during eventual refactor while using git-grep. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230117193014.83502-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
2023-01-28vhost-user: Skip unnecessary duplicated VHOST_USER_ADD/REM_MEM_REG requestsMinghao Yuan
The VHOST_USER_ADD/REM_MEM_REG requests should be categorized into non-vring specific messages, and should be sent only once. Signed-off-by: Minghao Yuan <yuanmh12@chinatelecom.cn> Message-Id: <20230123122119.194347-1-yuanmh12@chinatelecom.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-27vhost-user: Correct a reference of TARGET_AARCH64Akihiko Odaki
Presumably TARGET_ARM_64 should be a mistake of TARGET_AARCH64. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230109063130.81296-1-akihiko.odaki@daynix.com> Fixes: 27598393a2 ("Lift max memory slots limit imposed by vhost-user") Reviewed-by: Philippe Mathieu-Daudé <philmd@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-01-20Merge tag 'pull-include-2023-01-20' of https://repo.or.cz/qemu/armbru into ↵Peter Maydell
staging Header cleanup patches for 2023-01-20 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmPKN6YSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTPeoQAIKl/BF6PFRNq0/k3vPqMe6nltjgkpa/ # p7E5qRlo31RCeUB+f0iW26mySnNTgYkE28yy57HxUML/9Lp1bbxyDgRNiJ406a4L # kFVF04kOIFez1+mfvWN92DZqcl/EAAqNL6XqSFyO38kYwcsFsi+BZ7DLZbL9Ea8v # wVywB96mN6KyrLWCJ2D0OqIVuPHSHol+5zt9e6+ShBgN0FfElLbv0F4KH3VJ1olA # psKl6w6V9+c2zV1kT/H+S763m6mQdwtVo/UuOJoElI+Qib/UBxDOrhdYf4Zg7hKf # ByUuhJUASm8y9yD/42mFs90B6eUNzLSBC8v1PgRqSqDHtllveP4RysklBlyIMlOs # DKtqEuRuIJ/qDXliIFHY6tBnUkeITSd7BCxkQYfaGyaSOcviDSlE3AyaaBC0sY4F # P/lTTiRg5ksvhDYtJnW3mSfmT2PY7aBtyE3D1Z84v9hek6D0reMQTE97yL/j4m7P # wJP8aM3Z8GILCVxFIh02wmqWZhZUCGsIDS/vxVm+u060n66qtDIQFBoazsFJrCME # eWI+qDNDr6xhLegeYajGDM9pdpQc3x0siiuHso4wMSI9NZxwP+tkCVhTpqmrRcs4 # GSH/4IlUXqEZdUQDL38DfA22C1TV8BzyMhGLTUERWWYki1sr99yv0pdFyk5r3nLB # SURwr58rB2zo # =dOfq # -----END PGP SIGNATURE----- # gpg: Signature made Fri 20 Jan 2023 06:41:42 GMT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-include-2023-01-20' of https://repo.or.cz/qemu/armbru: include/hw/ppc include/hw/pci-host: Drop extra typedefs include/hw/ppc: Don't include hw/pci-host/pnv_phb.h from pnv.h include/hw/ppc: Supply a few missing includes include/hw/ppc: Split pnv_chip.h off pnv.h include/hw/block: Include hw/block/block.h where needed hw/sparc64/niagara: Use blk_name() instead of open-coding it include/block: Untangle inclusion loops coroutine: Use Coroutine typedef name instead of structure tag coroutine: Split qemu/coroutine-core.h off qemu/coroutine.h coroutine: Clean up superfluous inclusion of qemu/lockable.h coroutine: Move coroutine_fn to qemu/osdep.h, trim includes coroutine: Clean up superfluous inclusion of qemu/coroutine.h Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-01-20include/block: Untangle inclusion loopsMarkus Armbruster
We have two inclusion loops: block/block.h -> block/block-global-state.h -> block/block-common.h -> block/blockjob.h -> block/block.h block/block.h -> block/block-io.h -> block/block-common.h -> block/blockjob.h -> block/block.h I believe these go back to Emanuele's reorganization of the block API, merged a few months ago in commit d7e2fe4aac8. Fortunately, breaking them 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: <20221221133551.3967339-2-armbru@redhat.com>
2023-01-18bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plxPhilippe Mathieu-Daudé
The 'hwaddr' type is defined in "exec/hwaddr.h" as: hwaddr is the type of a physical address (its size can be different from 'target_ulong'). All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx: $ fgrep define include/exec/hwaddr.h #define HWADDR_H #define HWADDR_BITS 64 #define HWADDR_MAX UINT64_MAX #define TARGET_FMT_plx "%016" PRIx64 ^^^^^^ #define HWADDR_PRId PRId64 #define HWADDR_PRIi PRIi64 #define HWADDR_PRIo PRIo64 #define HWADDR_PRIu PRIu64 #define HWADDR_PRIx PRIx64 #define HWADDR_PRIX PRIX64 Since hwaddr's size can be *different* from target_ulong, it is very confusing to read one of its format using the 'TARGET_FMT_' prefix, normally used for the target_long / target_ulong types: $ fgrep TARGET_FMT_ include/exec/cpu-defs.h #define TARGET_FMT_lx "%08x" #define TARGET_FMT_ld "%d" #define TARGET_FMT_lu "%u" #define TARGET_FMT_lx "%016" PRIx64 #define TARGET_FMT_ld "%" PRId64 #define TARGET_FMT_lu "%" PRIu64 Apparently this format was missed during commit a8170e5e97 ("Rename target_phys_addr_t to hwaddr"), so complete it by doing a bulk-rename with: $ sed -i -e s/TARGET_FMT_plx/HWADDR_FMT_plx/g $(git grep -l TARGET_FMT_plx) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230110212947.34557-1-philmd@linaro.org> [thuth: Fix some warnings from checkpatch.pl along the way] Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-01-08virtio-pci: fix proxy->vector_irqfd leak in virtio_pci_set_guest_notifiersleixiang
proxy->vector_irqfd did not free when kvm_virtio_pci_vector_use or msix_set_vector_notifiers failed in virtio_pci_set_guest_notifiers. Fixes: 7d37d351 Signed-off-by: Lei Xiang <leixiang@kylinos.cn> Tested-by: Zeng Chi <zengchi@kylinos.cn> Suggested-by: Xie Ming <xieming@kylinos.cn> Message-Id: <20221227081604.806415-1-leixiang@kylinos.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08vdpa: commit all host notifier MRs in a single MR transactionLongpeng
This allows the vhost-vdpa device to batch the setup of all its MRs of host notifiers. This significantly reduces the device starting time, e.g. the time spend on setup the host notifier MRs reduce from 423ms to 32ms for a VM with 64 vCPUs and 3 vhost-vDPA generic devices (vdpa_sim_blk, 64vq per device). Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221227072015.3134-4-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-08vhost: configure all host notifiers in a single MR transactionLongpeng
This allows the vhost device to batch the setup of all its host notifiers. This significantly reduces the device starting time, e.g. the time spend on enabling notifiers reduce from 376ms to 9.1ms for a VM with 64 vCPUs and 3 vhost-vDPA generic devices (vdpa_sim_blk, 64vq per device) Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221227072015.3134-3-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-08vhost: simplify vhost_dev_enable_notifiersLongpeng
Simplify the error path in vhost_dev_enable_notifiers by using vhost_dev_disable_notifiers directly. Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221227072015.3134-2-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@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/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-08hw/virtio: Extract QMP QOM-specific functions to virtio-qmp.cPhilippe Mathieu-Daudé
virtio.c is big enough, extract more QMP related code to virtio-qmp.c. To do so, expose qmp_find_virtio_device() and declar virtio_list in the internal virtio-qmp.h header. Note we have to leave qmp_x_query_virtio_queue_status() and qmp_x_query_virtio_queue_element(), because they access VirtQueue internal fields, and VirtQueue is only declared within virtio.c. Suggested-by: Jonah Palmer <jonah.palmer@oracle.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221222080005.27616-3-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08hw/virtio: Rename virtio_device_find() -> qmp_find_virtio_device()Philippe Mathieu-Daudé
To emphasize this function is QMP related, rename it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221222080005.27616-2-philmd@linaro.org> 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-08virtio-mmio: add support for configure interruptCindy Lu
Add configure interrupt support in virtio-mmio bus. add function to set configure guest notifier. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-10-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-vdpa: add support for config interruptCindy Lu
Add new call back function in vhost-vdpa, The function vhost_set_config_call can set the event fd to kernel. This function will be called in the vhost_dev_start and vhost_dev_stop Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-6-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-pci: decouple the single vector from the interrupt processCindy Lu
To reuse the interrupt process in configure interrupt Need to decouple the single vector from the interrupt process. We add new function kvm_virtio_pci_vector_use_one and _release_one. These functions are used for the single vector, the whole process will finish in the loop with vq number. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-4-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-pci: decouple notifier from interrupt processCindy Lu
To reuse the notifier process. We add the virtio_pci_get_notifier to get the notifier and vector. The INPUT for this function is IDX, The OUTPUT is the notifier and the vector Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-3-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>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-22 01:56:34 +0000