Re: [PATCH v2] util: basic support for VFIO variant drivers

On Wed, May 31, 2023 at 01:18:44PM -0400, Laine Stump wrote: > On 5/31/23 10:31 AM, Jason Gunthorpe wrote: > > On Wed, May 31, 2023 at 03:18:17PM +0100, Joao Martins wrote: > > > Hey Laine, > > > > > > On 23/08/2022 15:11, Laine Stump wrote: > > > > ping. > > > > > > > > I have a different version of this patch where I do read the modules.alias file > > > > rather than just checking the name of the driver, but that also requires "double > > > > mocking" open() in the unit test, which wasn't working properly, and I'd rather > > > > not spend the time figuring it out if it's not going to be needed. (Alex prefers > > > > that version because it is more correct than just checking the name, and he's > > > > concerned that the new sysfs-based API may take longer than we're thinking to > > > > get into downstream distros, but the version in this patch does satisfy both > > > > Jason and Daniel's suggested implementations). Anyway, I can post the other > > > > patch if anyone is interested. > > > > > > > [sorry for the thread necromancy] > > Heh. I had actually dug out this same thread last week and started a mail to > ask Jason if the planned sysfs stuff had ever been pushed, but then forgot > to hit "send" :-) > > Now that there are multiple vfio variant drivers available (for igb, e1000e, > and mlx5 that I know of), Oh I haven't seen those intel ones posted yet? > Jason, can you point me at the information for this patch in an ELI5 manner > for a non-kernel person? (including what upstream kernel it's in, and what > it is that I need to look at to determine if a driver is a vfio > variant). It is this patch: commit 3c28a76124b25882411f005924be73795b6ef078 Author: Yi Liu <yi.l.liu(a)intel.com&gt; Date: Wed Sep 21 18:44:01 2022 +0800 vfio: Add struct device to vfio_device and replace kref. With it a 'vfio-dev/vfioX' node is created under the sysfs path of the parent, indicating the device is bound to a vfio driver, e.g.: /sys/devices/pci0000\:6f/0000\:6f\:01.0/vfio-dev/vfio0 It is also a preparatory step toward adding cdev for supporting future device-oriented uAPI. Add Documentation/ABI/testing/sysfs-devices-vfio-dev. Suggested-by: Jason Gunthorpe <jgg(a)nvidia.com&gt; Signed-off-by: Yi Liu <yi.l.liu(a)intel.com&gt; Signed-off-by: Kevin Tian <kevin.tian(a)intel.com&gt; Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com&gt; Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.tian@intel.com Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com&gt; $ git describe --contains 3c28a76124b25882411f005924be73795b6ef078 v6.1-rc1~42^2~35 So it is in v6.1-rc1 libvirt should start thinking about determining the vfioX number for the device, we will need that for iommufd enablement eventually so, stat for a directory like this: /sys/devices/pci0000\:6f/0000\:6f\:01.0/vfio-dev Confirms vfio Then scan it to get 'vfioX' which will eventually be the /dev/ node libvirt will have to open. And the other part is something in the stack should use the modalias mechanism to find load and bind the correct variant driver.