aboutsummaryrefslogtreecommitdiff
path: root/hw/virtio
AgeCommit message (Collapse)AuthorFilesLines
2023-02-06virtio-mem: Proper support for preallocation with migrationDavid Hildenbrand1-0/+87
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 Hildenbrand1-2/+49
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 Hildenbrand1-0/+6
"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 Armbruster2-0/+322
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 Kurz1-60/+5
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 Kurz1-32/+3
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é1-1/+2
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 Yuan1-0/+2
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 Odaki1-1/+1
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 Maydell1-0/+1
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 Armbruster1-0/+1
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é1-2/+2
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_notifiersleixiang1-0/+2
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 transactionLongpeng1-6/+19
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 transactionLongpeng1-0/+24
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_notifiersLongpeng1-16/+4
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 explicitlyLongpeng2-0/+16
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 Armbruster2-0/+2
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é3-191/+201
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é1-5/+5
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 Lu1-19/+99
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 Lu1-0/+27
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 Lu1-1/+77
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 Lu1-0/+29
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 Lu2-0/+9
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 Lu1-58/+73
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 Lu1-31/+57
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 Lu4-0/+64
To support configure interrupt for vhost-vdpa Introduce VIRTIO_CONFIG_IRQ_IDX -1 as configure interrupt's queue index, Then we can reuse the functions guest_notifier_mask and guest_notifier_pending. Add the check of queue index in these drivers, if the driver does not support configure interrupt, the function will just return Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221222070451.936503-2-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-28virtio-mem: Fix typo in function namePhilippe Mathieu-Daudé1-6/+6
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221228130956.80515-1-philmd@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com>
2022-12-28virtio-mem: Fix the iterator variable in a vmem->rdl_list loopChenyi Qiang1-1/+1
It should be the variable rdl2 to revert the already-notified listeners. Fixes: 2044969f0b ("virtio-mem: Implement RamDiscardManager interface") Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20221228090312.17276-1-chenyi.qiang@intel.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com>
2022-12-28virtio-mem: Fix the bitmap index of the section offsetChenyi Qiang1-2/+2
vmem->bitmap indexes the memory region of the virtio-mem backend at a granularity of block_size. To calculate the index of target section offset, the block_size should be divided instead of the bitmap_size. Fixes: 2044969f0b ("virtio-mem: Implement RamDiscardManager interface") Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20221216062231.11181-1-chenyi.qiang@intel.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: David Hildenbrand <david@redhat.com>
2022-12-21hw/virtio: Extract QMP related code virtio-qmp.cPhilippe Mathieu-Daudé4-634/+682
The monitor decoders are the only functions using the CONFIG_xxx definitions declared in the target specific CONFIG_DEVICES header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-7-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <a class="moz-txt-link-rfc2396E" href="mailto:philmd@linaro.org">&lt;philmd@linaro.org&gt;</a>
2022-12-21hw/virtio: Extract config read/write accessors to virtio-config-io.cPhilippe Mathieu-Daudé3-190/+205
These config helpers use the target-dependent LD/ST API. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-6-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/virtio: Constify qmp_virtio_feature_map_t[]Philippe Mathieu-Daudé1-17/+17
These arrays are only accessed read-only, move them to .rodata. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-5-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jonah Palmer<jonah.palmer@oracle.com> Signed-off-by: Philippe Mathieu-Daudé <a class="moz-txt-link-rfc2396E" href="mailto:philmd@linaro.org">&lt;philmd@linaro.org&gt;</a>
2022-12-21hw/virtio: Guard and restrict scope of qmp_virtio_feature_map_t[]Philippe Mathieu-Daudé1-14/+42
Commit f3034ad71f ("qmp: decode feature & status bits in virtio-status") did not guard all qmp_virtio_feature_map_t arrays with the corresponding #ifdef'ry used in qmp_decode_features(). Fix that and reduce the arrays scope by declaring them static. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-4-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jonah Palmer<jonah.palmer@oracle.com> Suggested-by: Richard Henderson <a class="moz-txt-link-rfc2396E" href="mailto:richard.henderson@linaro.org">&lt;richard.henderson@linaro.org&gt;</a> Signed-off-by: Philippe Mathieu-Daudé <a class="moz-txt-link-rfc2396E" href="mailto:philmd@linaro.org">&lt;philmd@linaro.org&gt;</a>
2022-12-21hw/virtio: Rename virtio_ss[] -> specific_virtio_ss[]Philippe Mathieu-Daudé1-21/+22
Since virtio_ss[] is added to specific_ss[], rename it as specific_virtio_ss[] to make it clearer. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-3-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/virtio: Add missing "hw/core/cpu.h" includePhilippe Mathieu-Daudé1-0/+1
virtio.c uses target_words_bigendian() which is declared in "hw/core/cpu.h". Add the missing header to avoid when refactoring: hw/virtio/virtio.c:2451:9: error: implicit declaration of function 'target_words_bigendian' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (target_words_bigendian()) { ^ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221213111707.34921-2-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vhost: fix vq dirty bitmap syncing when vIOMMU is enabledJason Wang1-20/+64
When vIOMMU is enabled, the vq->used_phys is actually the IOVA not GPA. So we need to translate it to GPA before the syncing otherwise we may hit the following crash since IOVA could be out of the scope of the GPA log size. This could be noted when using virtio-IOMMU with vhost using 1G memory. Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support") Cc: qemu-stable@nongnu.org Tested-by: Lei Yang <leiyang@redhat.com> Reported-by: Yalan Zhang <yalzhang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20221216033552.77087-1-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21vhost-user: send set log base message only onceYajun Wu1-0/+5
Vhost message VHOST_USER_SET_LOG_BASE is device wide. So only send it once with the first queue pair. Signed-off-by: Yajun Wu <yajunw@nvidia.com> Acked-by: Parav Pandit <parav@nvidia.com> Message-Id: <20221122051447.248462-1-yajunw@nvidia.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érez1-1/+2
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érez1-3/+3
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érez2-13/+27
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érez1-4/+0
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érez1-30/+2
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érez1-15/+0
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érez3-11/+8
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érez2-36/+30
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-21vhost: set SVQ device call handler at SVQ startEugenio Pérez1-2/+2
By the end of this series CVQ is shadowed as long as the features support it. Since we don't know at the beginning of qemu running if this is supported, move the event notifier handler setting to the start of the SVQ, instead of the start of qemu run. 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-3-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érez1-2/+2
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-21vdpa-dev: mark the device as unmigratableLongpeng1-0/+1
The generic vDPA device doesn't support migration currently, so mark it as unmigratable temporarily. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Longpeng <longpeng2@huawei.com> Message-Id: <20221215134944.2809-5-longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2024-12-27 13:10:34 +0000