Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] vdpa: alibaba: exporting generic virtio-net PCI ID breaks virtio_pci binding --
commit 56e367c85e2f18386c5a07775af8ff1e3da0457f Author: Pengpeng Hou <[email protected]> vdpa: alibaba: add missing MODULE_DEVICE_TABLE() This commit adds MODULE_DEVICE_TABLE(pci, eni_pci_ids) to the Alibaba ENI vDPA driver so that PCI module alias entries are generated for automatic module loading. > diff --git a/drivers/vdpa/alibaba/eni_vdpa.c b/drivers/vdpa/alibaba/eni_vdpa.c > index e476504db0c82..fd6fdba460945 100644 > --- a/drivers/vdpa/alibaba/eni_vdpa.c > +++ b/drivers/vdpa/alibaba/eni_vdpa.c > @@ -545,6 +545,7 @@ static struct pci_device_id eni_pci_ids[] = { > VIRTIO_ID_NET) }, > { 0 }, > }; > +MODULE_DEVICE_TABLE(pci, eni_pci_ids); > > static struct pci_driver eni_vdpa_driver = { > .name = "alibaba-eni-vdpa", [Severity: High] Will exporting eni_pci_ids via MODULE_DEVICE_TABLE() cause eni_vdpa to auto-load on standard non-Alibaba x86 VMs and race with virtio_pci for generic transitional or legacy virtio-net PCI devices? In drivers/vdpa/alibaba/eni_vdpa.c, eni_pci_ids matches the generic Virtio 0.9.5 / transitional Virtio 1.0 network device IDs rather than an Alibaba-specific PCI ID: drivers/vdpa/alibaba/eni_vdpa.c: static struct pci_device_id eni_pci_ids[] = { { PCI_DEVICE_SUB(PCI_VENDOR_ID_REDHAT_QUMRANET, VIRTIO_TRANS_ID_NET, PCI_SUBVENDOR_ID_REDHAT_QUMRANET, VIRTIO_ID_NET) }, { 0 }, }; These are the same PCI IDs (vendor 0x1af4, device 0x1000, subvendor 0x1af4, subdevice 0x0001) exposed by default virtio-net-pci devices in QEMU/KVM and matched by virtio_pci_id_table in drivers/virtio/virtio_pci_common.c: static const struct pci_device_id virtio_pci_id_table[] = { { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) }, { 0 } }; MODULE_DEVICE_TABLE(pci, virtio_pci_id_table); Previously, omitting MODULE_DEVICE_TABLE() prevented eni_vdpa from publishing a modalias for 1af4:1000, so it was only loaded when explicitly requested by userspace on Alibaba instances. With MODULE_DEVICE_TABLE() added, udev/kmod will auto-load eni_vdpa on any x86 guest with a transitional or legacy virtio-net-pci device when CONFIG_ALIBABA_ENI_VDPA=m and CONFIG_VIRTIO_PCI=m. In eni_vdpa_probe(), there is no hardware check distinguishing an Alibaba ENI device from a standard QEMU virtio-net-pci device: drivers/vdpa/alibaba/eni_vdpa.c:eni_vdpa_probe() { ... ldev = &eni_vdpa->ldev; ldev->pci_dev = pdev; ret = vp_legacy_probe(ldev); if (ret) { ENI_ERR(pdev, "failed to probe legacy PCI device\n"); goto err; } ... } If eni_vdpa probes the PCI device before virtio_pci, eni_vdpa_probe() -> vp_legacy_probe() succeeds and claims the device into the vDPA subsystem via vdpa_register_device(), preventing virtio_pci from binding and causing the guest to lose its standard virtio_net network interface. Was MODULE_DEVICE_TABLE() intentionally omitted here to avoid hijacking generic legacy/transitional virtio-net PCI devices from virtio_pci? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
