Re: [PATCH v2] util: basic support for VFIO variant drivers
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!