On Wed, Oct 22, 2025 at 08:33:55AM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 22, 2025 at 11:12:05AM +0200, Michał Winiarski wrote:
> > On Wed, Oct 22, 2025 at 01:54:42AM -0700, Christoph Hellwig wrote:
> > > On Wed, Oct 22, 2025 at 10:52:34AM +0200, Michał Winiarski wrote:
> > > > On Wed, Oct 22, 2025 at 12:12:01AM -0700, Christoph Hellwig wrote:
> > > > > There is absolutely nothing vendor-specific here, it is a device 
> > > > > variant
> > > > > driver.  In fact in Linux basically nothing is ever vendor specific,
> > > > > because vendor is not a concept that does matter in any practical 
> > > > > sense
> > > > > except for tiny details like the vendor ID as one of the IDs to match
> > > > > on in device probing.
> > > > > 
> > > > > I have no idea why people keep trying to inject this term again and
> > > > > again.
> > > > 
> > > > Hi,
> > > > 
> > > > The reasoning was that in this case we're matching vendor ID + class
> > > > combination to match all Intel GPUs, and not just selected device ID,
> > > > but I get your point.
> > > 
> > > Which sounds like a really bad idea.  Is this going to work on i810
> > > devices?  Or the odd parts povervr based parts?
> > 
> > It's using .override_only = PCI_ID_F_VFIO_DRIVER_OVERRIDE, so it only
> > matters if the user was already planning to override the regular driver
> > with VFIO one (using driver_override sysfs).
> > So if it worked on i810 or other odd parts using regular vfio-pci, it
> > would work with xe-vfio-pci, as both are using the same underlying
> > functions provided by vfio-pci-core.
> 
> I also would rather see you list the actual working PCI IDs :|
> 
> Claiming all class devices for a vendor_id is something only DRM
> does..

We already have all of the device IDs in include/drm/intel/pciids.h
So it's just a matter of adding a helper that sets an override and
including it and using a subset of ID.

I'll do that instead of matching on class.

Thanks,
-Michał

> 
> Jason

Reply via email to