summaryrefslogtreecommitdiffstats
path: root/hw/vfio
diff options
context:
space:
mode:
authorLongpeng(Mike)2022-03-26 07:02:25 +0100
committerAlex Williamson2022-05-06 17:06:50 +0200
commit75d546fc18023d36779c687b948128c1a4666a96 (patch)
tree7611847066972a63c7cd99025196d1f83086cdb9 /hw/vfio
parentvfio: simplify the failure path in vfio_msi_enable (diff)
downloadqemu-75d546fc18023d36779c687b948128c1a4666a96.tar.gz
qemu-75d546fc18023d36779c687b948128c1a4666a96.tar.xz
qemu-75d546fc18023d36779c687b948128c1a4666a96.zip
Revert "vfio: Avoid disabling and enabling vectors repeatedly in VFIO migration"
Commit ecebe53fe993 ("vfio: Avoid disabling and enabling vectors repeatedly in VFIO migration") avoids inefficiently disabling and enabling vectors repeatedly and lets the unmasked vectors be enabled one by one. But we want to batch multiple routes and defer the commit, and only commit once outside the loop of setting vector notifiers, so we cannot enable the vectors one by one in the loop now. Revert that commit and we will take another way in the next patch, it can not only avoid disabling/enabling vectors repeatedly, but also satisfy our requirement of defer to commit. Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com> Link: https://lore.kernel.org/r/20220326060226.1892-5-longpeng2@huawei.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Diffstat (limited to 'hw/vfio')
-rw-r--r--hw/vfio/pci.c20
1 files changed, 3 insertions, 17 deletions
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 50562629ea..8bc36f081a 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -572,9 +572,6 @@ static void vfio_msix_vector_release(PCIDevice *pdev, unsigned int nr)
static void vfio_msix_enable(VFIOPCIDevice *vdev)
{
- PCIDevice *pdev = &vdev->pdev;
- unsigned int nr, max_vec = 0;
-
vfio_disable_interrupts(vdev);
vdev->msi_vectors = g_new0(VFIOMSIVector, vdev->msix->entries);
@@ -593,22 +590,11 @@ static void vfio_msix_enable(VFIOPCIDevice *vdev)
* triggering to userspace, then immediately release the vector, leaving
* the physical device with no vectors enabled, but MSI-X enabled, just
* like the guest view.
- * If there are already unmasked vectors (in migration resume phase and
- * some guest startups) which will be enabled soon, we can allocate all
- * of them here to avoid inefficiently disabling and enabling vectors
- * repeatedly later.
*/
- if (!pdev->msix_function_masked) {
- for (nr = 0; nr < msix_nr_vectors_allocated(pdev); nr++) {
- if (!msix_is_masked(pdev, nr)) {
- max_vec = nr;
- }
- }
- }
- vfio_msix_vector_do_use(pdev, max_vec, NULL, NULL);
- vfio_msix_vector_release(pdev, max_vec);
+ vfio_msix_vector_do_use(&vdev->pdev, 0, NULL, NULL);
+ vfio_msix_vector_release(&vdev->pdev, 0);
- if (msix_set_vector_notifiers(pdev, vfio_msix_vector_use,
+ if (msix_set_vector_notifiers(&vdev->pdev, vfio_msix_vector_use,
vfio_msix_vector_release, NULL)) {
error_report("vfio: msix_set_vector_notifiers failed");
}