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....@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 <j...@nvidia.com>
Signed-off-by: Yi Liu <yi.l....@intel.com>
Signed-off-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Jason Gunthorpe <j...@nvidia.com>
Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.t...@intel.com
Signed-off-by: Alex Williamson <alex.william...@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.
Jason
