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

[Laine Stump]

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), it's getting more important to have 
them usable with libvirt, so I'm hoping to update this patch to use 
sysfs to determine if the driver is a vfio variant

>>
>> I was wondering if you're planning on respinning this work, or rather the
>> modalias approach alternative you mention? Or perhaps we are waiting for the
>> cdev sysfs? Though, there's still a significant amount of kernel versions to
>> cover that won't have the sysfs entry sadly :(
> 
> The cdev sysfs has been merged to the kernel now

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). Thanks!