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,
Alex
