lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230811095318.5ebcaa05.alex.williamson@redhat.com> Date: Fri, 11 Aug 2023 09:53:18 -0600 From: Alex Williamson <alex.williamson@...hat.com> To: Jason Gunthorpe <jgg@...dia.com> Cc: Christoph Hellwig <hch@....de>, "Tian, Kevin" <kevin.tian@...el.com>, Brett Creeley <bcreeley@....com>, Brett Creeley <brett.creeley@....com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "yishaih@...dia.com" <yishaih@...dia.com>, "shameerali.kolothum.thodi@...wei.com" <shameerali.kolothum.thodi@...wei.com>, "horms@...nel.org" <horms@...nel.org>, "shannon.nelson@....com" <shannon.nelson@....com> Subject: Re: [PATCH v14 vfio 6/8] vfio/pds: Add support for dirty page tracking On Thu, 10 Aug 2023 15:11:43 -0300 Jason Gunthorpe <jgg@...dia.com> 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@...dia.com> 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
Powered by blists - more mailing lists