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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux