On Thu, 10 Aug 2023 15:11:43 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Thu, Aug 10, 2023 at 11:54:44AM -0600, Alex Williamson wrote: > > On Thu, 10 Aug 2023 14:43:04 -0300 > > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > > On Thu, Aug 10, 2023 at 11:40:08AM -0600, Alex Williamson wrote: > > > > > > > PCI Express® Base Specification Revision 6.0.1, pg 1461: > > > > > > > > 9.3.3.11 VF Device ID (Offset 1Ah) > > > > > > > > This field contains the Device ID that should be presented for every VF to the SI. > > > > > > > > VF Device ID may be different from the PF Device ID... > > > > > > > > That? Thanks, > > > > > > NVMe matches using the class code, IIRC there is language requiring > > > the class code to be the same. > > > > Ok, yes: > > > > 7.5.1.1.6 Class Code Register (Offset 09h) > > ... > > The field in a PF and its associated VFs must return the same value > > when read. > > > > Seems limiting, but it's indeed there. We've got a lot of cleanup to > > do if we're going to start rejecting drivers for devices with PCI > > spec violations though ;) Thanks, > > Well.. If we defacto say that Linux is endorsing ignoring this part of > the spec then I predict we will see more vendors follow this approach. The NVMe driver will claim PCI_CLASS_STORAGE_EXPRESS devices, but there are also various vendor/device IDs in the table, some for the purpose of setting driver data with quirks, some not. So I think the spec compliant behavior here would be that the VF replicates the PF class code and we'd simply need to add the vendor/device explicitly to the id table. TBH, I can see why this spec requirement might get overlooked, it's a rather arbitrary restriction of the VF device. Thanks, Alex
