On Mon, Feb 26, 2024 at 11:55:56AM -0700, Alex Williamson wrote:
> This will be the first intel vfio-pci variant driver, I don't think we
> need an intel sub-directory just yet.
>
> Tangentially, I think an issue we're running into with
> PCI_DRIVER_OVERRIDE_DEVICE_VFIO is that we require driver_override to
> bind the device and therefore the id_table becomes little more than a
> suggestion. Our QE is already asking, for example, if they should use
> mlx5-vfio-pci for all mlx5 compatible devices.
They don't have to, but it works fine, there is no reason not to.
I imagined that users would always bind the variant driver, it is why
the drivers all have "disabled" fallbacks to just be normal vfio-pci.
> I wonder if all vfio-pci variant drivers that specify an id_table
> shouldn't include in their probe function:
>
> if (!pci_match_id(pdev, id)) {
> pci_info(pdev, "Incompatible device, disallowing driver_override\n");
> return -ENODEV;
> }
Certainly an interesting idea, doesn't that completely defeat driver
binding and new_id though?
You are worried about someone wrongly loading a mlx5 driver on, say,
an Intel device?
> (And yes, I see the irony that vfio introduced driver_override and
> we've created variant drivers that require driver_override and now we
> want to prevent driver_overrides)
Heh
> Jason, are you seeing any of this as well and do you have a better
> suggestion how we might address the issue? Thanks,
I haven't heard of confusion here.. People who don't care just use
vfio-pci like the internet tells them, people who do care seem to be
very sophisticated right now..
Did the userspace tool Max sketched out to automatically parse the id
tables ever get completed? That seems like the best solution, just
automate it and remove the decision from the user.
Jason
