[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26f50be4-1195-ae7f-844f-5babff158bee@amd.com>
Date: Mon, 14 Aug 2023 11:41:36 -0700
From: Brett Creeley <bcreeley@....com>
To: "Tian, Kevin" <kevin.tian@...el.com>, Jason Gunthorpe <jgg@...dia.com>,
Alex Williamson <alex.williamson@...hat.com>
Cc: Christoph Hellwig <hch@....de>, 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 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@...dia.com>
>> 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@...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.
>>
>
> 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.
Thanks,
Brett
Powered by blists - more mailing lists