> From: Zeng, Xin <xin.zeng@xxxxxxxxx>
> Sent: Monday, March 4, 2024 7:11 PM
>
> On Saturday, March 2, 2024 7:59 AM, Alex Williamson
> <alex.williamson@xxxxxxxxxx> wrote:
> > On Wed, 28 Feb 2024 22:34:02 +0800
> > Xin Zeng <xin.zeng@xxxxxxxxx> wrote:
> > > +static int
> > > +qat_vf_vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> > *id)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + struct qat_vf_core_device *qat_vdev;
> > > + int ret;
> > > +
> > > + if (!pci_match_id(id, pdev)) {
> > > + pci_err(pdev, "Incompatible device, disallowing
> > driver_override\n");
> > > + return -ENODEV;
> > > + }
> >
> > I think the question of whether this is the right thing to do is still
> > up for debate, but as noted in the thread where I raised the question,
> > this mechanism doesn't actually work.
> >
> > The probe callback is passed the matching ID from the set of dynamic
> > IDs added via new_id, the driver id_table, or pci_device_id_any for a
> > strictly driver_override match. Any of those would satisfy
> > pci_match_id().
> >
> > If we wanted the probe function to exclusively match devices in the
> > id_table, we should call this as:
> >
> > if (!pci_match_id(qat_vf_vfio_pci_table, pdev))...
> >
> > If we wanted to still allow dynamic IDs, the test might be more like:
> >
> > if (id == &pci_device_id_any)...
> >
> > Allowing dynamic IDs but failing driver_override requires a slightly
> > more sophisticated user, but is inconsistent. Do we have any
> > consensus on this? Thanks,
> >
>
> As migration support is required to be reported at probe time in the
> variant driver, and migration support is device specific, the variant
> driver should be considered as device specific driver, not a general
> purpose vfio-pci stand-in.
> From this point of view, maybe it's not necessary to allow dynamic id
> arbitrarily, matching devices in the id_table provided by the variant
> driver exclusively would be the preference. If this sound good to you,
> I'll update the implementation (to use the correct id table) in next
> version.
I'm leaning toward this view too. Somehow driver_override is more
restrictive than dynamic IDs based on its description then it sounds
a bit weird that on one hand we are doing strict match upon static
table but on the other hand lifting the bar for dynamic IDs.
If consensus cannot be reached quickly I prefer to not adding
the match and wait to change all drivers together when it
is made later.
