On Mon, Feb 26, 2024 at 12:41:07PM -0700, Alex Williamson wrote: > On Mon, 26 Feb 2024 15:12:20 -0400 > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > 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. > > But there's also no reason to. None of the metadata exposed by the > driver suggests it should be a general purpose vfio-pci stand-in. I think the intent was to bind it to all the devices in its ID table automatically for VFIO use and it should always be OK to do that. Not doing so is a micro optimization. Userspace binding it to other random things is a Bad Thing. > > You are worried about someone wrongly loading a mlx5 driver on, say, > > an Intel device? > > That's sort of where we're headed if we consider it valid to bind a CX5 > to mlx5-vfio-pci just because they have a host driver with a similar > name in common. I hope nobody is doing that, everyone should be using a tool that checks that ID table.. If we lack a usable tool for that then it that is the problemm. > It's essentially a free for all. I worry about test matrices, user > confusion, and being on guard for arbitrary devices at every turn in > variant drivers if our policy is that they should all work > equivalent to a basic vfio-pci-core implementation for anything. Today most of the drivers will just NOP themeslves if they can't find a compatible PF driver, the most likely bug in this path would be a NULL ptr deref or something in an untested path, or just total failure to bind. We could insist that VF drivers are always able to find their PF or binding fails, that would narrow things considerably. > libvirt recently implemented support for managed="yes" with variant > drivers where it will find the best "vfio_pci" driver for a device > using an algorithm like Max suggested, but in practice it's not clear > how useful that will be considering devices likes CX7 require > configuration before binding to the variant driver. libvirt has no > hooks to specify or perform configuration at that point. I don't think this is fully accurate (or at least not what was intended), the VFIO device can be configured any time up until the VM mlx5 driver reaches the device startup. Is something preventing this? Did we accidentally cache the migratable flag in vfio or something?? > The driverctl script also exists and could maybe consider the > "vfio-pci" driver name to be a fungible alias for the best matching > vfio_pci class driver, but I'm not sure if driverctl has a sufficient > following to make a difference. I was also thinking about this tool as an alternative instruction to using libvirt. Maybe this would ecourage more people to use it if it implemented it? Jason
