On Mon, Feb 26, 2024 at 03:24:58PM -0700, Alex Williamson wrote: > On Mon, 26 Feb 2024 15:49:52 -0400 > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > 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. > > Automatic in what sense? We use PCI_DRIVER_OVERRIDE_DEVICE_VFIO to set > the id_table entry to override_only, so any binding requires the user > to specify a driver_override. Nothing automatically performs that > driver_override except the recent support in libvirt for "managed" > devices. I mean in the sense the user would run some command it would find the right driver.. > Effectively override_only negates the id_table to little more than a > suggestion to userspace of how the driver should be used. We once talked about having a "flavor" sysfs in the driver core where instead of using driver_override you'd switch flavours to vfio and then it would use the driver binding logic to get the right driver. I forget why we abandoned that direction.. > > checks that ID table.. If we lack a usable tool for that then it that > > is the problemm. > > These are the sort of questions I'm currently fielding and yes, we > don't really have any tools to make this automatic outside of the > recent libvirt support. I see. Having people do this manually was not my vision at a least. > > > 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?? > > I don't think so, I think this was just the policy we had decided > relative to profiling VFs when they're created rather than providing a > means to do it though a common vfio variant driver interface[1]. I didn't quite mean it so literally though, I imagined we could bind the driver in VFIO, profile the VF, then open the VFIO cdev. > Nothing necessarily prevents libvirt from configuring devices after > binding to a vfio-pci variant driver, but per the noted thread the > upstream policy is to have the device configured prior to giving it to > vfio and any configuration mechanisms are specific to the device and > variant driver, therefore what more is libvirt to do? I admit I don't have a clear sense what the plan here is on the userspace side. Somehow this all has to be threaded together and a real environment needs a step to profile and provision these complex VFIO devices. For k8s I think we are doing this with the operator plugins. I don't know of a plan for "raw" libvirt.. > OTOH, libvirt is more targeted and while it will work automatically for > a "managed" device specified via domain xml, it's also available as a > utility through virsh, ex: > > # virsh nodedev-detach pci_0000_01_10_0 > > Which should trigger the code to bind to vfio-pci or the best variant > driver. Maybe we just need to more clearly document this? > Relative to variant driver probe() re-checking the id_table, I know we > generally don't try to set policy in the kernel and this sort of > behavior has been around for a long, long time with new_id, but the > barrier to entry has been substantially lowered with things like > driverctl that I'd still entertain the idea. Thanks, I'm not adverse to it, but maybe we should try to push the userspace forward some more before putting kernel protections in? Jason
