On Wed, 31 May 2023 14:30:52 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > 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@xxxxxxxxx> > 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@xxxxxxxxxx> > Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx> > Signed-off-by: Kevin Tian <kevin.tian@xxxxxxxxx> > Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.tian@xxxxxxxxx > Signed-off-by: Alex Williamson <alex.williamson@xxxxxxxxxx> > > $ 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. I'd forgotten about this as well, so after binding a driver to a device we can tell if that driver presents a vfio interface by looking for this sysfs directory. Prior to binding to a device, we can only know if a driver provides a vfio interface through modalias. Also note that we're saying "vfio" not "vfio-pci". Only the mdev interface has the device_api attribute to indicate the exported vfio device interface. The "vfio_pci:" match in modalias indicates a vfio PCI driver, not necessarily a driver that provides a vfio-pci API. We have no current examples to the contrary, but for instance I wouldn't recommend validating whether mode='subsystem' type='pci' is appropriate based on that information. Thanks, Alex
