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>
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>
Signed-off-by: Yi Liu <yi.l.liu(a)intel.com>
Signed-off-by: Kevin Tian <kevin.tian(a)intel.com>
Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com>
Link: https://lore.kernel.org/r/20220921104401.38898-16-kevin.tian@intel.com
Signed-off-by: Alex Williamson <alex.williamson(a)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