Re: [libvirt PATCH v2 15/15] qemu: automatically bind to a vfio variant driver, if available

On 11/28/23 10:39 AM, Peter Krempa wrote: > On Mon, Nov 06, 2023 at 02:39:00 -0500, Laine Stump wrote: > > Rather than always binding to the vfio-pci driver, use the new > > function virPCIDeviceFindBestVFIOVariant() to see if the running > > kernel has a VFIO variant driver available that is a better match for > > the device, and if one is found, use that instead. > > > > virPCIDeviceFindBestVFIOVariant() function reads the modalias file for > > the given device from sysfs, then looks through > > /lib/modules/${kernel_release}/modules.alias for the vfio_pci alias > > that matches with the least number of wildcard ('*') fields. > > > > The appropriate "VFIO variant" driver for a device will be the PCI > > driver implemented by the discovered module - these drivers are > > compatible with (and provide the entire API of) the standard vfio-pci > > driver, but have additional device-specific APIs that can be useful > > for, e.g., saving/restoring state for migration. > > > > If a specific driver is named, that will still be used rather than > > searching modules.alias; this makes it possible to force binding of > > vfio-pci if there is an issue with the auto-selected variant driver. > > > > Signed-off-by: Laine Stump <laine(a)redhat.com&gt; > > --- > > src/util/virpci.c | 242 ++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 242 insertions(+)

> > + > > + uname(&unameInfo); > > + modulesAliasPath = g_strdup_printf("/lib/modules/%s/modules.alias", > > + unameInfo.release); > > + if (virFileReadAll(modulesAliasPath, > > + 4 * 1024 * 1024, &modulesAliasContent) < 0) { > > Note that the file currently has 1.3MiB already, I'm not sure what the > potenital for growth is though, but this leaves less than an order of > magnitude in reserve. How about increasing it to 8MB? Still too small?

> Additionally the code below only currently looks at 2 of the 25k lines > in the file. Maybe it's worth caching the relevant lines? Yes, I agree with this. I suppose the "proper" way to do that is to use virfilecache (code re-use and all that), but it will take me some time to understand that, as I've never looked at it until just now :-P. How about a promise to do a followup "soon" that caches the useful lines and re-uses them?