On Thu, 21 Sep 2023 16:20:59 -0400
"Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
> On Thu, Sep 21, 2023 at 05:01:21PM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 21, 2023 at 01:58:32PM -0600, Alex Williamson wrote:
> >
> > > > +static const struct pci_device_id virtiovf_pci_table[] = {
> > > > + { PCI_DRIVER_OVERRIDE_DEVICE_VFIO(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
> > >
> > > libvirt will blindly use this driver for all devices matching this as
> > > we've discussed how it should make use of modules.alias. I don't think
> > > this driver should be squatting on devices where it doesn't add value
> > > and it's not clear whether this is adding or subtracting value in all
> > > cases for the one NIC that it modifies. How should libvirt choose when
> > > and where to use this driver? What regressions are we going to see
> > > with VMs that previously saw "modern" virtio-net devices and now see a
> > > legacy compatible device? Thanks,
> >
> > Maybe this approach needs to use a subsystem ID match?
> >
> > Jason
>
> Maybe make users load it manually?
>
> Please don't bind to virtio by default, you will break
> all guests.
This would never bind by default, it's only bound as a vfio override
driver, but if libvirt were trying to determine the correct driver to
use with vfio for a 0x1af4 device, it'd land on this one. Thanks,
Alex
