[PATCH 0/2] Fix support for monolithic kernels (no module support)
Hi all, This series fixes libvirt compilation and runtime on systems using a monolithic kernel compiled without module support (CONFIG_MODULES=n). Currently, libvirt assumes kernel module support is always available, which causes build failures or runtime errors on such systems. Changes: - virpci: don't fail VFIO passthrough when modules.alias is missing - virpci: don"t fail VFIO passthrough when /sys/module/*/drivers is inaccessible. Tested on kernel 6.18 with grsecurity and a custom monolithic kernel. Note this issue has previously been reported there: https://gitlab.com/libvirt/libvirt/-/work_items/591 Thanks, Baptiste Daroussin
When modules.alias is not available (e.g. monolithic kernel), virPCIDeviceFindBestVFIOVariant() would fail, causing the entire PCI device detach to abort. Instead, log a warning and return success with no variant found, allowing the caller to fall back to the generic vfio-pci driver. Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com> --- src/util/virpci.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/util/virpci.c b/src/util/virpci.c index d43fa1ef54..fa04264a95 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1459,6 +1459,12 @@ virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev, uname(&unameInfo); modulesAliasPath = g_strdup_printf("/lib/modules/%s/modules.alias", unameInfo.release); + if (!virFileExists(modulesAliasPath)) { + /* on monolithic kernel this file does not exist */ + VIR_DEBUG("modules.alias not available (%s), skipping VFIO variant detection", + modulesAliasPath); + return 0; + } if (virFileReadAll(modulesAliasPath, 8 * 1024 * 1024, &modulesAliasContent) < 0) return -1; -- 2.43.0
On monolythic kernel /sys/modules/*/drivers may not exist (ENOENT) On kernels with enhanced security (e.g. grsecurity), it might not be accessible: EACCESS or EPERM. Directly try to open if it fails with any of those errors, we fallback on the module name. Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com> --- src/util/virpci.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index fa04264a95..ec22eac7c9 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1287,8 +1287,21 @@ virPCIDeviceFindDriver(virPCIDevice *dev) moduleDriversDir = g_strdup_printf("/sys/module/%s/drivers", moduleName); - if (virDirOpen(&dir, moduleDriversDir) < 0) + if (virDirOpenQuiet(&dir, moduleDriversDir) < 0) { + /* with monolithic kernels this directory will not exist: ENOENT + * with hardened system like grsecurity or any MAC frameowrk it might be be accessible: + * EACCESS or EPERM. + */ + if (errno == ENOENT || errno == EACCES || errno == EPERM) { + VIR_DEBUG("driver directory not available (%s), using module name as driver name", + moduleDriversDir); + g_free(dev->stubDriverName); + dev->stubDriverName = g_steal_pointer(&moduleName); + return 0; + } + virReportSystemError(errno, _("cannot open directory '%1$s'"), moduleDriversDir); return -1; + } while (virDirRead(dir, &ent, moduleDriversDir) > 0) { -- 2.43.0
On Mon, Apr 20, 2026 at 15:02:56 +0200, Baptiste Daroussin wrote:
Hi all,
This series fixes libvirt compilation and runtime on systems using a monolithic kernel compiled without module support (CONFIG_MODULES=n).
Currently, libvirt assumes kernel module support is always available, which causes build failures or runtime errors on such systems.
Changes: - virpci: don't fail VFIO passthrough when modules.alias is missing - virpci: don"t fail VFIO passthrough when /sys/module/*/drivers is inaccessible.
s/don"t/don't/ in the summary of the second commit.
Tested on kernel 6.18 with grsecurity and a custom monolithic kernel.
Note this issue has previously been reported there: https://gitlab.com/libvirt/libvirt/-/work_items/591
My comments from v1 (on the MR on gitlab) were addressed so: Reviewed-by: Peter Krempa <pkrempa@redhat.com> But I'd like to leave some time for folks dealing more with VFIO - e.g. Laine - to comment on this if there are any issues I don't see.
participants (2)
-
Baptiste Daroussin -
Peter Krempa