On Wed, 31 May 2023 14:30:52 -0300 Jason Gunthorpe <jgg@nvidia.com> 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@intel.com> 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@nvidia.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.tian@intel.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
$ 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