Re: [PATCH AUTOSEL 6.18-6.1] vdpa: alibaba: add missing MODULE_DEVICE_TABLE()

[sashiko-bot@kernel.org]

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 <pengpeng@iscas.ac.cn>

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/20261019135441.1420968-253-sashal@kernel.org?part=1