aboutsummaryrefslogtreecommitdiff
path: root/hw/virtio/vhost-vdpa.c
AgeCommit message (Collapse)Author
2023-06-23hw/virtio: Remove unnecessary 'virtio-access.h' headerPhilippe Mathieu-Daudé
None of these files use the VirtIO Load/Store API declared by "hw/virtio/virtio-access.h". This header probably crept in via copy/pasting, remove it. Note, "virtio-access.h" is target-specific, so any file including it also become tainted as target-specific. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230524093744.88442-10-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
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-vdpa: Add check for full 64-bit in region deleteCindy Lu
The unmap ioctl doesn't accept a full 64-bit span. So need to add check for the section's size in vhost_vdpa_listener_region_del(). Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20230510054631.2951812-4-lulu@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19vhost_vdpa: fix the input in trace_vhost_vdpa_listener_region_del()Cindy Lu
In trace_vhost_vdpa_listener_region_del, the value for llend should change to int128_get64(int128_sub(llend, int128_one())) Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20230510054631.2951812-3-lulu@redhat.com> 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-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-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-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-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>
2022-12-21vdpa: always start CVQ in SVQ mode if possibleEugenio Pérez
Isolate control virtqueue in its own group, allowing to intercept control commands but letting dataplane run totally passthrough to the guest. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20221215113144.322011-13-eperezma@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>
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: allocate SVQ array unconditionallyEugenio Pérez
SVQ may run or not in a device depending on runtime conditions (for example, if the device can move CVQ to its own group or not). Allocate the SVQ array unconditionally at startup, since its hard to move this allocation elsewhere. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-9-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: move SVQ vring features check to net/Eugenio Pérez
The next patches will start control SVQ if possible. However, we don't know if that will be possible at qemu boot anymore. Since the moved checks will be already evaluated at net/ to know if it is ok to shadow CVQ, move them. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-8-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: request iova_range only onceEugenio Pérez
Currently iova range is requested once per queue pair in the case of net. Reduce the number of ioctls asking it once at initialization and reusing that value for each vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20221215113144.322011-7-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasonwang@redhat.com>
2022-12-21vhost: move iova_tree set to vhost_svq_startEugenio Pérez
Since we don't know if we will use SVQ at qemu initialization, let's allocate iova_tree only if needed. To do so, accept it at SVQ start, not at initialization. This will avoid to create it if the device does not support SVQ. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-5-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vhost: allocate SVQ device file descriptors at device startEugenio Pérez
The next patches will start control SVQ if possible. However, we don't know if that will be possible at qemu boot anymore. Delay device file descriptors until we know it at device start. This will avoid to create them if the device does not support SVQ. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-4-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vdpa: use v->shadow_vqs_enabled in vhost_vdpa_svqs_start & stopEugenio Pérez
This function used to trust in v->shadow_vqs != NULL to know if it must start svq or not. This is not going to be valid anymore, as qemu is going to allocate svq array unconditionally (but it will only start them conditionally). Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221215113144.322011-2-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-14error: Move ERRP_GUARD() to the beginning of the functionMarkus Armbruster
include/qapi/error.h advises to put ERRP_GUARD() right at the beginning of the function, because only then can it guard the whole function. Clean up the few spots disregarding the advice. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221121085054.683122-4-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2022-09-02vdpa: Delete CVQ migration blockerEugenio Pérez
We can restore the device state in the destination via CVQ now. Remove the migration blocker. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vdpa: Use ring hwaddr at vhost_vdpa_svq_unmap_ringEugenio Pérez
Reduce code duplication. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vdpa: Make SVQ vring unmapping return voidEugenio Pérez
Nothing actually reads the return value, but an error in cleaning some entries could cause device stop to abort, making a restart impossible. Better ignore explicitely the return value. Reported-by: Lei Yang <leiyang@redhat.com> Fixes: 34e3c94eda ("vdpa: Add custom IOTLB translations to SVQ") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vdpa: Remove SVQ vring from iova_tree at shutdownEugenio Pérez
Although the device will be reset before usage, the right thing to do is to clean it. Reported-by: Lei Yang <leiyang@redhat.com> Fixes: 34e3c94eda ("vdpa: Add custom IOTLB translations to SVQ") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02util: accept iova_tree_remove_parameter by valueEugenio Pérez
It's convenient to call iova_tree_remove from a map returned from iova_tree_find or iova_tree_find_iova. With the current code this is not possible, since we will free it, and then we will try to search for it again. Fix it making accepting the map by value, forcing a copy of the argument. Not applying a fixes tag, since there is no use like that at the moment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vdpa: do not save failed dma maps in SVQ iova treeEugenio Pérez
If a map fails for whatever reason, it must not be saved in the tree. Otherwise, qemu will try to unmap it in cleanup, leaving to more errors. Fixes: 34e3c94eda ("vdpa: Add custom IOTLB translations to SVQ") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vdpa: Skip the maps not in the iova treeEugenio Pérez
Next patch will skip the registering of dma maps that the vdpa device rejects in the iova tree. We need to consider that here or we cause a SIGSEGV accessing result. Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-26vdpa: Fix memory listener deletions of iova treeEugenio Pérez
vhost_vdpa_listener_region_del is always deleting the first iova entry of the tree, since it's using the needle iova instead of the result's one. This was detected using a vga virtual device in the VM using vdpa SVQ. It makes some extra memory adding and deleting, so the wrong one was mapped / unmapped. This was undetected before since all the memory was mappend and unmapped totally without that device, but other conditions could trigger it too: * mem_region was with .iova = 0, .translated_addr = (correct GPA). * iova_tree_find_iova returned right result, but does not update mem_region. * iova_tree_remove always removed region with .iova = 0. Right iova were sent to the device. * Next map will fill the first region with .iova = 0, causing a mapping with the same iova and device complains, if the next action is a map. * Next unmap will cause to try to unmap again iova = 0, causing the device to complain that no region was mapped at iova = 0. Fixes: 34e3c94edaef ("vdpa: Add custom IOTLB translations to SVQ") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-26vhost: Get vring base from vq, not svqEugenio Pérez
The SVQ vring used idx usually match with the guest visible one, as long as all the guest buffers (GPA) maps to exactly one buffer within qemu's VA. However, as we can see in virtqueue_map_desc, a single guest buffer could map to many buffers in SVQ vring. Also, its also a mistake to rewind them at the source of migration. Since VirtQueue is able to migrate the inflight descriptors, its responsability of the destination to perform the rewind just in case it cannot report the inflight descriptors to the device. This makes easier to migrate between backends or to recover them in vhost devices that support set in flight descriptors. Fixes: 6d0b22266633 ("vdpa: Adapt vhost_vdpa_get_vring_base to SVQ") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-20vdpa: Add device migration blockerEugenio Pérez
Since the vhost-vdpa device is exposing _F_LOG, adding a migration blocker if it uses CVQ. However, qemu is able to migrate simple devices with no CVQ as long as they use SVQ. To allow it, add a placeholder error to vhost_vdpa, and only add to vhost_dev when used. vhost_dev machinery place the migration blocker if needed. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-20vdpa: manual forward CVQ buffersEugenio Pérez
Do a simple forwarding of CVQ buffers, the same work SVQ could do but through callbacks. No functional change intended. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-20vdpa: Export vhost_vdpa_dma_map and unmap callsEugenio Pérez
Shadow CVQ will copy buffers on qemu VA, so we avoid TOCTOU attacks from the guest that could set a different state in qemu device model and vdpa device. To do so, it needs to be able to map these new buffers to the device. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-07-20vhost: Add svq avail_handler callbackEugenio Pérez
This allows external handlers to be aware of new buffers that the guest places in the virtqueue. When this callback is defined the ownership of the guest's virtqueue element is transferred to the callback. This means that if the user wants to forward the descriptor it needs to manually inject it. The callback is also free to process the command by itself and use the element with svq_push. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-05-16vhost-vdpa: change name and polarity for vhost_vdpa_one_time_request()Si-Wei Liu
The name vhost_vdpa_one_time_request() was confusing. No matter whatever it returns, its typical occurrence had always been at requests that only need to be applied once. And the name didn't suggest what it actually checks for. Change it to vhost_vdpa_first_dev() with polarity flipped for better readibility of code. That way it is able to reflect what the check is really about. This call is applicable to request which performs operation only once, before queues are set up, and usually at the beginning of the caller function. Document the requirement for it in place. Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Message-Id: <1651890498-24478-7-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2022-05-16vhost-vdpa: backend feature should set only onceSi-Wei Liu
The vhost_vdpa_one_time_request() branch in vhost_vdpa_set_backend_cap() incorrectly sends down ioctls on vhost_dev with non-zero index. This may end up with multiple VHOST_SET_BACKEND_FEATURES ioctl calls sent down on the vhost-vdpa fd that is shared between all these vhost_dev's. To fix it, send down ioctl only once via the first vhost_dev with index 0. Toggle the polarity of the vhost_vdpa_one_time_request() test should do the trick. Fixes: 4d191cfdc7de ("vhost-vdpa: classify one time request") Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <1651890498-24478-6-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-05-13vdpa: Fix index calculus at vhost_vdpa_svqs_startEugenio Pérez
With the introduction of MQ the index of the vq needs to be calculated with the device model vq_index. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220512175747.142058-5-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-05-13vdpa: Fix bad index calculus at vhost_vdpa_get_vring_baseEugenio Pérez
Fixes: 6d0b222666 ("vdpa: Adapt vhost_vdpa_get_vring_base to SVQ") Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20220512175747.142058-4-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-26vdpa: Add missing tracing to batch mapping functionsEugenio Pérez
These functions were not traced properly. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220405063628.853745-1-eperezma@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-04-06include: move C/util-related declarations to cutils.hMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-22-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-06Replace qemu_real_host_page variables with inlined functionsMarc-André Lureau
Replace the global variables with inlined helper functions. getpagesize() is very likely annotated with a "const" function attribute (at least with glibc), and thus optimization should apply even better. This avoids the need for a constructor initialization too. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-12-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-31vhost-vdpa: fix typo in a commentStefano Garzarella
Replace vpda with vdpa. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220328152022.73245-1-sgarzare@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-03-15vdpa: Expose VHOST_F_LOG_ALL on SVQEugenio Pérez
SVQ is able to log the dirty bits by itself, so let's use it to not block migration. Also, ignore set and clear of VHOST_F_LOG_ALL on set_features if SVQ is enabled. Even if the device supports it, the reports would be nonsense because SVQ memory is in the qemu region. The log region is still allocated. Future changes might skip that, but this series is already long enough. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-07 02:16:02 +0000