aboutsummaryrefslogtreecommitdiff
path: root/hw/virtio
AgeCommit message (Collapse)Author
2023-07-12virtio-mem-pci: Device unplug supportDavid Hildenbrand
Let's support device unplug by forwarding the unplug_request_check() callback to the virtio-mem device. Further, disallow changing the requested-size once an unplug request is pending. Disallowing requested-size changes handles corner cases such as (1) pausing the VM (2) requesting device unplug and (3) adjusting the requested size. If the VM would plug memory (due to the requested size change) before processing the unplug request, we would be in trouble. Message-ID: <20230711153445.514112-8-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-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-12virtio-md-pci: Handle unplug of virtio based memory devicesDavid Hildenbrand
While we fence unplug requests from the outside, the VM can still trigger unplug of virtio based memory devices, for example, in Linux doing on a virtio-mem-pci device: # echo 0 > /sys/bus/pci/slots/3/power While doing that is not really expected to work without harming the guest OS (e.g., removing a virtio-mem device while it still provides memory), let's make sure that we properly handle it on the QEMU side. We'll add support for unplugging of virtio-mem devices in some configurations next. Message-ID: <20230711153445.514112-5-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-12virtio-mem: Support "x-ignore-shared" migrationDavid Hildenbrand
To achieve desired "x-ignore-shared" functionality, we should not discard all RAM when realizing the device and not mess with preallocation/postcopy when loading device state. In essence, we should not touch RAM content. As "x-ignore-shared" gets set after realizing the device, we cannot rely on that. Let's simply skip discarding of RAM on incoming migration. Note that virtio_mem_post_load() will call virtio_mem_restore_unplugged() -- unless "x-ignore-shared" is set. So once migration finished we'll have a consistent state. The initial system reset will also not discard any RAM, because virtio_mem_unplug_all() will not call virtio_mem_unplug_all() when no memory is plugged (which is the case before loading the device state). Note that something like VM templating -- see commit b17fbbe55cba ("migration: allow private destination ram with x-ignore-shared") -- is currently incompatible with virtio-mem and ram_block_discard_range() will warn in case a private file mapping is supplied by virtio-mem. For VM templating with virtio-mem, it makes more sense to either (a) Create the template without the virtio-mem device and hotplug a virtio-mem device to the new VM instances using proper own memory backend. (b) Use a virtio-mem device that doesn't provide any memory in the template (requested-size=0) and use private anonymous memory. Message-ID: <20230706075612.67404-5-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-12virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memoryDavid Hildenbrand
Already when starting QEMU we perform one system reset that ends up triggering virtio_mem_unplug_all() with no actual memory plugged yet. That, in turn will trigger ram_block_discard_range() and perform some other actions that are not required in that case. Let's optimize virtio_mem_unplug_all() for the case that no memory is plugged. This will be beneficial for x-ignore-shared support as well. Message-ID: <20230706075612.67404-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-07-10vhost: Fix false positive out-of-boundsHawkins Jiawei
QEMU uses vhost_svq_translate_addr() to translate addresses between the QEMU's virtual address and the SVQ IOVA. In order to validate this translation, QEMU checks whether the translated range falls within the mapped range. Yet the problem is that, the value of `needle_last`, which is calculated by `needle.translated_addr + iovec[i].iov_len`, should represent the exclusive boundary of the translated range, rather than the last inclusive addresses of the range. Consequently, QEMU fails the check when the translated range matches the size of the mapped range. This patch solves this problem by fixing the `needle_last` value to the last inclusive address of the translated range. Note that this bug cannot be triggered at the moment, because QEMU is unable to translate such a big range due to the truncation of the CVQ command in vhost_vdpa_net_handle_ctrl_avail(). Fixes: 34e3c94eda ("vdpa: Add custom IOTLB translations to SVQ") Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Message-Id: <ee31c5420ffc8e6a29705ddd30badb814ddbae1d.1688743107.git.yin31149@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/virtio: fix typo in VIRTIO_CONFIG_IRQ_IDX commentsAlex Bennée
Fixes: 544f0278af (virtio: introduce macro VIRTIO_CONFIG_IRQ_IDX) Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-4-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: Rework the traces in virtio_iommu_set_page_size_mask()Eric Auger
The current error messages in virtio_iommu_set_page_size_mask() sound quite similar for different situations and miss the IOMMU memory region that causes the issue. Clarify them and rework the comment. Also remove the trace when the new page_size_mask is not applied as the current frozen granule is kept. This message is rather confusing for the end user and anyway the current granule would have been used by the driver. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20230705165118.28194-3-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>
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-10vhost-vdpa: mute unaligned memory error reportLaurent Vivier
With TPM CRM device, vhost-vdpa reports an error when it tries to register a listener for a non aligned memory region: qemu-system-x86_64: vhost_vdpa_listener_region_add received unaligned region qemu-system-x86_64: vhost_vdpa_listener_region_del received unaligned region This error can be confusing for the user whereas we only need to skip the region (as it's already done after the error_report()) Rather than introducing a special case for TPM CRB memory section to not display the message in this case, simply replace the error_report() by a trace function (with more information, like the memory region name). Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20230704071931.575888-2-lvivier@redhat.com> Reviewed-by: David Hildenbrand <david@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-07-10vhost-user: Make RESET_DEVICE a per device messageTom Lonergan
A device reset is issued per device, not per VQ. The legacy device reset message, VHOST_USER_RESET_OWNER, is already a per device message. Therefore, this change adds the proper message, VHOST_USER_RESET_DEVICE, to per device messages. Signed-off-by: Tom Lonergan <tom.lonergan@nutanix.com> Message-Id: <20230628163927.108171-3-tom.lonergan@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2023-07-10vhost-user: Change one_time to per_device requestTom Lonergan
Some devices, like virtio-scsi, consist of one vhost_dev, while others, like virtio-net, contain multiple vhost_devs. The QEMU vhost-user code has a concept of one-time messages which is misleading. One-time messages are sent once per operation on the device, not once for the lifetime of the device. Therefore, as discussed in [1], vhost_user_one_time_request should be renamed to vhost_user_per_device_request and the relevant comments updated to match the real functionality. [1] https://lore.kernel.org/qemu-devel/20230127083027-mutt-send-email-mst@kernel.org/ Signed-off-by: Tom Lonergan <tom.lonergan@nutanix.com> Message-Id: <20230628163927.108171-2-tom.lonergan@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2023-07-10hw/virtio: Add vhost-user-scmi-pci boilerplateMilan Zamazal
This allows is to instantiate a vhost-user-scmi device as part of a PCI bus. It is mostly boilerplate similar to the other vhost-user-*-pci boilerplates of similar devices. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Message-Id: <20230628100524.342666-3-mzamazal@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.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-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-07-10vdpa: Remove status in reset tracingEugenio Pérez
It is always 0 and it is not useful to route call through file descriptor. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230526153736.472443-1-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-28exec/memory: Add symbol for memory listener priority for device backendIsaku Yamahata
Add MEMORY_LISTENER_PRIORITY_DEV_BACKEND for the symbolic value for memory listener to replace the hard-coded value 10 for the device backend. No functional change intended. Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <8314d91688030d7004e96958f12e2c83fb889245.1687279702.git.isaku.yamahata@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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-26vhost: fix vhost_dev_enable_notifiers() error caseLaurent Vivier
in vhost_dev_enable_notifiers(), if virtio_bus_set_host_notifier(true) fails, we call vhost_dev_disable_notifiers() that executes virtio_bus_set_host_notifier(false) on all queues, even on queues that have failed to be initialized. This triggers a core dump in memory_region_del_eventfd(): virtio_bus_set_host_notifier: unable to init event notifier: Too many open files (-24) vhost VQ 1 notifier binding failed: 24 .../softmmu/memory.c:2611: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. Fix the problem by providing to vhost_dev_disable_notifiers() the number of queues to disable. Fixes: 8771589b6f81 ("vhost: simplify vhost_dev_enable_notifiers") Cc: longpeng2@huawei.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20230602162735.3670785-1-lvivier@redhat.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-06-26vdpa: map shadow vrings with MAP_SHAREDEugenio Pérez
The vdpa devices that use va addresses neeeds these maps shared. Otherwise, vhost_vdpa checks will refuse to accept the maps. The mmap call will always return a page aligned address, so removing the qemu_memalign call. Keeping the ROUND_UP for the size as we still need to DMA-map them in full. Not applying fixes tag as it never worked with va devices. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230602143854.1879091-4-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-23virtio-mem: Simplify bitmap handling and virtio_mem_set_block_state()David Hildenbrand
Let's separate plug and unplug handling to prepare for future changes and make the code a bit easier to read -- working on block states (plugged/unplugged) instead of on a bitmap. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Gavin Shan <gshan@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230523183036.517957-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-23vhost: release virtqueue objects in error pathPrasad Pandit
vhost_dev_start function does not release virtqueue objects when event_notifier_init() function fails. Release virtqueue objects and log a message about function failure. Signed-off-by: Prasad Pandit <pjp@fedoraproject.org> Message-Id: <20230529114333.31686-3-ppandit@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: f9a09ca3ea ("vhost: add support for configure interrupt") Reviewed-by: Peter Xu <peterx@redhat.com> Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com>
2023-06-23vhost: release memory_listener object in error pathPrasad Pandit
vhost_dev_start function does not release memory_listener object in case of an error. This may crash the guest when vhost is unable to set memory table: stack trace of thread 125653: Program terminated with signal SIGSEGV, Segmentation fault #0 memory_listener_register (qemu-kvm + 0x6cda0f) #1 vhost_dev_start (qemu-kvm + 0x699301) #2 vhost_net_start (qemu-kvm + 0x45b03f) #3 virtio_net_set_status (qemu-kvm + 0x665672) #4 qmp_set_link (qemu-kvm + 0x548fd5) #5 net_vhost_user_event (qemu-kvm + 0x552c45) #6 tcp_chr_connect (qemu-kvm + 0x88d473) #7 tcp_chr_new_client (qemu-kvm + 0x88cf83) #8 tcp_chr_accept (qemu-kvm + 0x88b429) #9 qio_net_listener_channel_func (qemu-kvm + 0x7ac07c) #10 g_main_context_dispatch (libglib-2.0.so.0 + 0x54e2f) Release memory_listener objects in the error path. Signed-off-by: Prasad Pandit <pjp@fedoraproject.org> Message-Id: <20230529114333.31686-2-ppandit@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Fixes: c471ad0e9b ("vhost_net: device IOTLB support") Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com>
2023-06-23hw/virtio: Build various target-agnostic objects just oncePhilippe Mathieu-Daudé
The previous commit remove the unnecessary "virtio-access.h" header. These files no longer have target-specific dependency. Move them to the generic 'softmmu_ss' source set. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230524093744.88442-11-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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-06-23hw/virtio/virtio-iommu: Use target-agnostic qemu_target_page_mask()Philippe Mathieu-Daudé
In order to have virtio-iommu.c become target-agnostic, we need to avoid using TARGET_PAGE_MASK. Get it with the qemu_target_page_mask() helper. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20230524093744.88442-9-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-06-23hw/virtio/vhost-vsock: Include missing 'virtio/virtio-bus.h' headerPhilippe Mathieu-Daudé
Instead of having "virtio/virtio-bus.h" implicitly included, explicitly include it, to avoid when rearranging headers: hw/virtio/vhost-vsock-common.c: In function ‘vhost_vsock_common_start’: hw/virtio/vhost-vsock-common.c:51:5: error: unknown type name ‘VirtioBusClass’; did you mean ‘VirtioDeviceClass’? 51 | VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus); | ^~~~~~~~~~~~~~ | VirtioDeviceClass hw/virtio/vhost-vsock-common.c:51:25: error: implicit declaration of function ‘VIRTIO_BUS_GET_CLASS’; did you mean ‘VIRTIO_DEVICE_CLASS’? [-Werror=implicit-function-declaration] 51 | VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus); | ^~~~~~~~~~~~~~~~~~~~ | VIRTIO_DEVICE_CLASS Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230524093744.88442-8-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> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2023-06-23hw/virtio/virtio-mem: Use qemu_ram_get_fd() helperPhilippe Mathieu-Daudé
Avoid accessing RAMBlock internals, use the provided qemu_ram_get_fd() getter to get the file descriptor. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230524093744.88442-7-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-06-23hw/virtio: Introduce VHOST_VSOCK_COMMON symbol in KconfigPhilippe Mathieu-Daudé
Instead of adding 'vhost-vsock-common.c' twice (for VHOST_VSOCK and VHOST_USER_VSOCK), have it depend on VHOST_VSOCK_COMMON, selected by both symbols. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230524093744.88442-6-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> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2023-06-23cryptodev-vhost-user: add asymmetric crypto supportGowrishankar Muthukrishnan
Add asymmetric crypto support in vhost_user backend. Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com> Message-Id: <20230516083139.2349744-1-gmuthukrishn@marvell.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-20meson: Replace softmmu_ss -> system_ssPhilippe Mathieu-Daudé
We use the user_ss[] array to hold the user emulation sources, and the softmmu_ss[] array to hold the system emulation ones. Hold the latter in the 'system_ss[]' array for parity with user emulation. Mechanical change doing: $ sed -i -e s/softmmu_ss/system_ss/g $(git grep -l softmmu_ss) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230613133347.82210-10-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-06-09hw/virtio/virtio-qmp.c: spelling: suppotedMichael Tokarev
Fixes: f3034ad71fcd0a6a58bc37830f182b307f089159 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de>
2023-06-05bulk: Remove pointless QOM castsPhilippe Mathieu-Daudé
Mechanical change running Coccinelle spatch with content generated from the qom-cast-macro-clean-cocci-gen.py added in the previous commit. Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230601093452.38972-3-philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-30aio: remove aio_disable_external() APIStefan Hajnoczi
All callers now pass is_external=false to aio_set_fd_handler() and aio_set_event_notifier(). The aio_disable_external() API that temporarily disables fd handlers that were registered is_external=true is therefore dead code. Remove aio_disable_external(), aio_enable_external(), and the is_external arguments to aio_set_fd_handler() and aio_set_event_notifier(). The entire test-fdmon-epoll test is removed because its sole purpose was testing aio_disable_external(). Parts of this patch were generated using the following coccinelle (https://coccinelle.lip6.fr/) semantic patch: @@ expression ctx, fd, is_external, io_read, io_write, io_poll, io_poll_ready, opaque; @@ - aio_set_fd_handler(ctx, fd, is_external, io_read, io_write, io_poll, io_poll_ready, opaque) + aio_set_fd_handler(ctx, fd, io_read, io_write, io_poll, io_poll_ready, opaque) @@ expression ctx, notifier, is_external, io_read, io_poll, io_poll_ready; @@ - aio_set_event_notifier(ctx, notifier, is_external, io_read, io_poll, io_poll_ready) + aio_set_event_notifier(ctx, notifier, io_read, io_poll, io_poll_ready) Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230516190238.8401-21-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-05-30virtio: do not set is_external=true on host notifiersStefan Hajnoczi
Host notifiers can now use is_external=false since virtio-blk and virtio-scsi no longer rely on is_external=true for drained sections. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230516190238.8401-20-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-05-30virtio: make it possible to detach host notifier from any threadStefan Hajnoczi
virtio_queue_aio_detach_host_notifier() does two things: 1. It removes the fd handler from the event loop. 2. It processes the virtqueue one last time. The first step can be peformed by any thread and without taking the AioContext lock. The second step may need the AioContext lock (depending on the device implementation) and runs in the thread where request processing takes place. virtio-blk and virtio-scsi therefore call virtio_queue_aio_detach_host_notifier() from a BH that is scheduled in AioContext. The next patch will introduce a .drained_begin() function that needs to call virtio_queue_aio_detach_host_notifier(). .drained_begin() functions cannot call aio_poll() to wait synchronously for the BH. It is possible for a .drained_poll() callback to asynchronously wait for the BH, but that is more complex than necessary here. Move the virtqueue processing out to the callers of virtio_queue_aio_detach_host_notifier() so that the function can be called from any thread. This is in preparation for the next patch. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230516190238.8401-17-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-05-28virtio-input-pci: add virtio-multitouch-pciSergio Lopez
Add virtio-multitouch-pci, a Multitouch-capable input device, to the list of devices that can be provided by virtio-input-pci. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230526112925.38794-5-slp@redhat.com>
2023-05-26virtio: qmp: fix memory leakPaolo Bonzini
The VirtioInfoList is already allocated by QAPI_LIST_PREPEND and need not be allocated by the caller. Fixes Coverity CID 1508724. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-23hostmem-file: add offset optionAlexander Graf
Add an option for hostmem-file to start the memory object at an offset into the target file. This is useful if multiple memory objects reside inside the same target file, such as a device node. In particular, it's useful to map guest memory directly into /dev/mem for experimentation. To make this work consistently, also fix up all places in QEMU that expect fd offsets to be 0. Signed-off-by: Alexander Graf <graf@amazon.com> Message-Id: <20230403221421.60877-1-graf@amazon.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Hildenbrand <david@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-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-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-05-19virtio-crypto: fix NULL pointer dereference in virtio_crypto_free_requestMauro Matteo Cascella
Ensure op_info is not NULL in case of QCRYPTODEV_BACKEND_ALG_SYM algtype. Fixes: 0e660a6f90a ("crypto: Introduce RSA algorithm") Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com> Reported-by: Yiming Tao <taoym@zju.edu.cn> Message-Id: <20230509075317.1132301-1-mcascell@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: zhenwei pi<pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19vhost-user: Remove acpi-specific memslot limitDavid Hildenbrand
Let's just support 512 memslots on x86-64 and aarch64 as well. The maximum number of ACPI slots (256) is no longer completely expressive ever since we supported virtio-based memory devices. Further, we're completely ignoring other memslots used outside of memory device context, such as memslots used for boot memory. Note that the vhost memslot limit in the kernel is usually configured to be 509. With this change, we prepare vhost-user on the QEMU side to be closer to that limit, to eventually support ~512 memslots in most vhost implementations and have less "surprises" when cold/hotplugging vhost devices while also consuming more memslots than we're currently used to by memory devices (e.g., once virtio-mem starts using multiple memslots). Note that most vhost-user implementations only support a small number of memslots so far, which we can hopefully improve in the near future. We'll leave the PPC special-case as is for now. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230503184144.808478-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-05-19virtio-mem: Default to "unplugged-inaccessible=on" with 8.1 on x86-64David Hildenbrand
Allowing guests to read unplugged memory simplified the bring-up of virtio-mem in Linux guests -- which was limited to x86-64 only. On arm64 (which was added later), we never had legacy guests and don't even allow to configure it, essentially always having "unplugged-inaccessible=on". At this point, all guests we care about should be supporting VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, so let's change the default for the 8.1 machine. This change implies that also memory that supports the shared zeropage (private anonymous memory) will now require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE in the driver in order to be usable by the guest -- as default, one can still manually set the unplugged-inaccessible property. Disallowing the guest to read unplugged memory will be important for some future features, such as memslot optimizations or protection of unplugged memory, whereby we'll actually no longer allow the guest to even read from unplugged memory. At some point, we might want to deprecate and remove that property. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20230503182352.792458-1-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>