> From: Brett Creeley <bcreeley@xxxxxxx>
> Sent: Tuesday, August 15, 2023 2:42 AM
>
> On 8/10/2023 8:25 PM, Tian, Kevin wrote:
> > Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> >
> >
> >> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> >> Sent: Friday, August 11, 2023 2:12 AM
> >>
> >> 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.
> >>
> >
> > Looks PCI core assumes the class code must be same across VFs (though
> > not cross PF/VF). And it even violates the spec to require Revision ID
> > and Subsystem ID must be same too:
> >
> > static void pci_read_vf_config_common(struct pci_dev *virtfn)
> > {
> > struct pci_dev *physfn = virtfn->physfn;
> >
> > /*
> > * Some config registers are the same across all associated VFs.
> > * Read them once from VF0 so we can skip reading them from the
> > * other VFs.
> > *
> > * PCIe r4.0, sec 9.3.4.1, technically doesn't require all VFs to
> > * have the same Revision ID and Subsystem ID, but we assume they
> > * do.
> > */
> > pci_read_config_dword(virtfn, PCI_CLASS_REVISION,
> > &physfn->sriov->class);
> > pci_read_config_byte(virtfn, PCI_HEADER_TYPE,
> > &physfn->sriov->hdr_type);
> > pci_read_config_word(virtfn, PCI_SUBSYSTEM_VENDOR_ID,
> > &physfn->sriov->subsystem_vendor);
> > pci_read_config_word(virtfn, PCI_SUBSYSTEM_ID,
> > &physfn->sriov->subsystem_device);
> > }
> >
> > Does AMD distributed card provide multiple PF's each for a class of
> > VF's or a single PF for all VF's?
>
> Hey Kevin,
>
> The AMD Pensando DSC provides multiple PFs for each class of VFs.
> All of our production devices will meet the assumptions of the pci core
> function above that all VFs match VF0 for those common fields.
>
> I've been out for a few days so apologies for the delayed response.
>
Sounds good. No more open then. 😊
