On Thu, Jan 04, 2024 at 20:01:44 -0500, Laine Stump wrote:
> 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@xxxxxxxxxx>
> > > ---
> > > 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?
Ideally we'd stream-process the file, since the code looks at single
lines at time, I'm not sure whether we have some prior art in this
regard.
> > 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?
Honestly I don't think there's too much value in caching it on disk. A
runtime cache would be fine.
It's fine from my side if it's done later. If you keep reading of the
contents into a buffer and processing that add a comment stating that it
might not be enough. The code will break once the file size exceeds the
buffer size.
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
