> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Thursday, December 14, 2023 4:24 AM
>
> On Wed, 13 Dec 2023 14:25:10 +0200
> Yishai Hadas <yishaih@xxxxxxxxxx> wrote:
>
> > On 13/12/2023 10:23, Tian, Kevin wrote:
>
> > >> +
> > >> +static int virtiovf_pci_probe(struct pci_dev *pdev,
> > >> + const struct pci_device_id *id)
> > >> +{
> > >> + const struct vfio_device_ops *ops = &virtiovf_vfio_pci_ops;
> > >> + struct virtiovf_pci_core_device *virtvdev;
> > >> + int ret;
> > >> +
> > >> + if (pdev->is_virtfn && virtio_pci_admin_has_legacy_io(pdev) &&
> > >> + !virtiovf_bar0_exists(pdev))
> > >> + ops = &virtiovf_vfio_pci_tran_ops;
> > >
> > > I have a confusion here.
> > >
> > > why do we want to allow this driver binding to non-matching VF or
> > > even PF?
> >
> > The intention is to allow the binding of any virtio-net device (i.e. PF,
> > VF which is not transitional capable) to have a single driver over VFIO
> > for all virtio-net devices.
> >
> > This enables any user space application to bind and use any virtio-net
> > device without the need to care.
> >
> > In case the device is not transitional capable, it will simply use the
> > generic vfio functionality.
>
> The algorithm we've suggested for finding the most appropriate variant
> driver for the device doesn't include a step of moving on to another
> driver if the binding fails. We lose determinism at that point.
> Therefore this driver needs to handle all devices matching the id table.
> The fact that virtio dictates various config space fields limits our
> ability to refine the match from the id table. Thanks,
>
OK, that makes sense.
