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@redhat.com> --- 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.