On Tue, Apr 13, 2021 at 11:36:22AM +0800, Longfang Liu wrote:
Register the live migration driver of the accelerator module to vfio
Signed-off-by: Longfang Liu <liulongfang@huawei.com> drivers/vfio/pci/vfio_pci.c | 11 +++++++++++ drivers/vfio/pci/vfio_pci_private.h | 9 +++++++++ 2 files changed, 20 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c index 65e7e6b..e1b0e37 100644 +++ b/drivers/vfio/pci/vfio_pci.c @@ -407,6 +407,17 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev) } }
+ if (pdev->vendor == PCI_VENDOR_ID_HUAWEI && + IS_ENABLED(CONFIG_VFIO_PCI_HISI_MIGRATION)) { + ret = vfio_pci_hisilicon_acc_init(vdev);
This is exactly what we want to avoid with the work we are doing on the vfio-pci modularity. It is a complete mess to just keep adding more stuff here, and as we've discussed to death really ugly to have such a ridiculously wide ID match. You should be working with us on that project and base your work on top of Max's series.. Alex given the interest here I think we should find some way forward while we work on completed version of the mlx5 pci vfio driver.. I'm also confused how this works securely at all, as a general rule a VFIO PCI driver cannot access the MMIO memory of the function it is planning to assign to the guest. There is a lot of danger that the guest could access that MMIO space one way or another. Here I see the driver obtaining a devm_ioremap() of the same pdev it is going to assign (and I really wonder why pci_release_mem_regions() exists at all..) This is why the mlx5 RFC was showing how to juggle two PCI devices via the aux device connector. Jason