On Mon, Oct 23, 2023 at 12:54:37AM -0400, Laine Stump wrote: > When we recently gained the ability to manually specify a driver to > bind to with virsh nodedev-detach, the fragility of this system became > apparent - if a user gives the driver name as "vfio_pci", then we > would modprobe the module, but then erroneously believe it hadn't been > loaded because /sys/bus/pci/drivers/vfio_pci didn't exist. For manual > specification of the driver name, this could be dealt with by telling > the user "always use the correct name for the driver, don't assume > that it is the same as the modulename", but it would still end up > confusing people, especially since some drivers do use underscore in > their name (e.g. the mlx5_vfio_pci driver/module). I think you are creating more confusion by allowing this. The driver name from module.alias should be used consistently in its exact format. Log a 'did you mean XYZ" or something if it doesn't work out. Pass the "driver name" directly to modprobe and let it sort it out Forget about modules entirely in the libvirt level, don't even check it. > c) All of this is conveniently ignoring the possibility of a VFIO > variant driver that is statically linked in the kernel. The entire > design of variant driver auto-detection is based on doing a lookup > in modules.alias, and that only lists *loadable modules* (not > drivers), so unless I'm missing something, it would be impossible > to auto-detect a VFIO variant driver that was statically > linked. This is beyond libvirt's ability to fix; the best that > could be done would be to manually specify the driver name in the > libvirt config, which I suppose is better than nothing :-) Why? This seems wrong. Statically linked drivers appear in /sys/bus/drivers/XX too Jason
