Re: [PATCH v4 05/10] samples/devsec: Introduce a PCI device-security bus + endpoint sample

[dan.j.williams]

Gerd Hoffmann wrote:
> On Wed, Aug 06, 2025 at 11:33:18AM -0700, dan.j.williams@xxxxxxxxx wrote:
> > Jonathan Cameron wrote:
> > > 
> > > +CC Gerd, of off chance we can use a Redhat PCI device ID for kernel
> > > emulation similar to those they let Qemu use.
> > > 
> > [..]
> > > > > Emulating something real?  If not maybe we should get an ID from another space
> > > > > (or reserve this one ;)  
> > > > 
> > > > I am happy to switch to something else, but no, I do not have time to
> > > > chase this through PCI SIG. I do not expect this id to cause conflicts,
> > > > but no guarantees.
> > > 
> > > Nothing to do with the SIG - you definitely don't want to try talking them
> > > into giving a Vendor ID for the kernel.  That's an Intel ID so you need to find
> > > the owner of whatever tracker Intel uses for these.
> > 
> > About the same level of difficulty...
> > 
> > > Or maybe we can ask for one of the Redhat ones (maintained by Gerd).
> 
> Well, they are meant for virtual devices emulated by qemu (and the
> registry is docs/specs/pci-ids.rst in the qemu repo).
> 
> We made exceptions to that rule before (linux/samples/vfio-mdev/mdpy.c
> got one for example).  So feel free to try sending a patch with an
> update to qemu-devel.  There should be a /good/ explanation why you want
> go that route, and "I'm to lazy to get one from my employer" is not what
> I'd consider "good".  Also it's qemu release freeze and vacation season
> right now, so don't expect this process to be fast.

Thanks for the details Gerd. IIUC that samples/vfio-mdev/ example is for
a functional use case. samples/devsec/ is not a functional use case. It
does not need an exclusive id to enable some limited unit testing. If
samples/devsec/ ever causes real world conflict the resolution is turn
it off / refrain from loading it.