Re: [PATCH] util: basic support for vendor-specific vfio drivers
On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote:
> > That is reasonable, but I'd say those three kernels
only have two
> > drivers and they both have vfio as a substring in their name - so the
> > simple thing of just substring searching 'vfio' would get us over that
> > gap.
>
> Looking at the aliases for exactly "vfio_pci" isn't that much more
> complicated, and "feels" a lot more reliable than just doing a substring
> search for "vfio" in the driver's name. (It would be, uh, ....
"not
> smart" to name a driver "vfio<anything>" if it wasn't
actually a vfio
> variant driver (or the opposite), but I could imagine it happening; :-/)
This is still pretty hacky. I'm worried about what happens to the
kernel if this becames some crazy unintended uAPI that we never really
thought about carefully... This was not a use case when we designed
the modules.alias stuff at least.
BTW - why not do things the normal way?
1. readlink /sys/bus/pci/devices/XX/iommu_group
2. Compute basename of #1
3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2)
It has a small edge case where a multi-device group might give a false
positive for an undrivered device, but for the purposes of libvirt
that seems pretty obscure.. (while the above has false negative
issues, obviously)
> Since we already need to do something else as a stop-gap for the
interim
> (in order to avoid making driver developers wait any longer if for no
> other reason), my opinion would be to not spend extra time splitting up
> patches just to give us this functionality slightly sooner; we'll anyway
> have something at least workable in place.
We also need to be careful in adding things piecemeal that libvirt can
determine when new functionality, such as vfio device chardevs, are
actually available and not simply a placeholder to fill a gap
elsewhere.
In sysfs the kernel standard is the directory means there is a "struct
device" and the "dev" file within the directory means there is a cdev,
so it is safely discoverable.
I would like to split the kernel patch anyhow because the cdev is
conceptually complicated so having just the struct device bits on its
own would be helpful..
Jason