From: Matthew Gerlach <[email protected]>
Add documentation on identifying FPGA based PCI cards prompted
by discussion on the [email protected] mailing list.
Signed-off-by: Matthew Gerlach <[email protected]>
---
v2: Introduced in v2.
---
Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index ef9eec71f6f3..5fb2ca8e76d7 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver with matched feature id.
FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
could be a reference.
+PCI Device Identification
+================================
+Since FPGA based PCI cards can be reconfigured to a perform a completely
+new function at runtime, properly identifying such cards and binding the
+correct driver can be challenging. In many use cases, deployed FPGA based
+PCI cards are essentially static and the PCI Product ID and Vendor ID pair
+is sufficient to identify the card. The DFL framework helps with the
+dynamic case of deployed FPGA cards changing at run time by providing
+more detailed information about card discoverable at runtime.
+
+At one level, the DFL on a PCI card describes the function of the card.
+However, the same DFL could be instantiated on different physical cards.
+Conversely, different DFLs could be instantiated on the same physical card.
+Practical management of a cloud containing a heterogeneous set of such cards
+requires a PCI level of card identification. While the PCI Product ID and
+Vendor ID may be sufficient to bind the dfl-pci driver, it is expected
+that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem
+Vendor ID values. PCI Vital Product Data (VPD) can also be used for
+more granular information about the board.
+
Location of DFLs on a PCI Device
================================
The original method for finding a DFL on a PCI device assumed the start of the
--
2.25.1
On 3/2/22 4:35 PM, [email protected] wrote:
> From: Matthew Gerlach <[email protected]>
>
> Add documentation on identifying FPGA based PCI cards prompted
> by discussion on the [email protected] mailing list.
>
> Signed-off-by: Matthew Gerlach <[email protected]>
> ---
> v2: Introduced in v2.
> ---
> Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> index ef9eec71f6f3..5fb2ca8e76d7 100644
> --- a/Documentation/fpga/dfl.rst
> +++ b/Documentation/fpga/dfl.rst
> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver with matched feature id.
> FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
> could be a reference.
>
> +PCI Device Identification
> +================================
> +Since FPGA based PCI cards can be reconfigured to a perform a completely
> +new function at runtime, properly identifying such cards and binding the
> +correct driver can be challenging. In many use cases, deployed FPGA based
> +PCI cards are essentially static and the PCI Product ID and Vendor ID pair
> +is sufficient to identify the card. The DFL framework helps with the
> +dynamic case of deployed FPGA cards changing at run time by providing
> +more detailed information about card discoverable at runtime.
> +
> +At one level, the DFL on a PCI card describes the function of the card.
> +However, the same DFL could be instantiated on different physical cards.
> +Conversely, different DFLs could be instantiated on the same physical card.
> +Practical management of a cloud containing a heterogeneous set of such cards
> +requires a PCI level of card identification. While the PCI Product ID and
> +Vendor ID may be sufficient to bind the dfl-pci driver, it is expected
> +that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem
> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for
> +more granular information about the board.
This describes a bit more of the problem, it should describe it wrt ofs
dev id. The introduction of the ofs dev should be explicitly called out
as a generic pci id.
Why couldn't one of the old pci id's be reused ?
How will the subvendor/subid be enforced ?
Is the current security manager patchset smart enough to save the board
from being bricked when a user doesn't look beyond the pci id ?
What happens if a board uses this device id but doesn't have a max10 to
do the update ?
Tom
> +
> Location of DFLs on a PCI Device
> ================================
> The original method for finding a DFL on a PCI device assumed the start of the
On Fri, 4 Mar 2022, Russ Weight wrote:
>
>
> On 3/3/22 14:04, Tom Rix wrote:
>>
>> On 3/2/22 4:35 PM, [email protected] wrote:
>>> From: Matthew Gerlach <[email protected]>
>>>
>>> Add documentation on identifying FPGA based PCI cards prompted
>>> by discussion on the [email protected] mailing list.
>>>
>>> Signed-off-by: Matthew Gerlach <[email protected]>
>>> ---
>>> v2: Introduced in v2.
>>> ---
>>> Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
>>> index ef9eec71f6f3..5fb2ca8e76d7 100644
>>> --- a/Documentation/fpga/dfl.rst
>>> +++ b/Documentation/fpga/dfl.rst
>>> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver with matched feature id.
>>> FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
>>> could be a reference.
>>> +PCI Device Identification
>>> +================================
>>> +Since FPGA based PCI cards can be reconfigured to a perform a completely
>>> +new function at runtime, properly identifying such cards and binding the
>>> +correct driver can be challenging. In many use cases, deployed FPGA based
>>> +PCI cards are essentially static and the PCI Product ID and Vendor ID pair
>>> +is sufficient to identify the card. The DFL framework helps with the
>>> +dynamic case of deployed FPGA cards changing at run time by providing
>>> +more detailed information about card discoverable at runtime.
>>> +
>>> +At one level, the DFL on a PCI card describes the function of the card.
>>> +However, the same DFL could be instantiated on different physical cards.
>>> +Conversely, different DFLs could be instantiated on the same physical card.
>>> +Practical management of a cloud containing a heterogeneous set of such cards
>>> +requires a PCI level of card identification. While the PCI Product ID and
>>> +Vendor ID may be sufficient to bind the dfl-pci driver, it is expected
>>> +that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem
>>> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for
>>> +more granular information about the board.
>>
>> This describes a bit more of the problem, it should describe it wrt ofs dev id. The introduction of the ofs dev should be explicitly called out as a generic pci id.
The problem I'm describing exists for all FPGA based PCI cards; so I am
purposely trying to be abstract as much as possible.
>>
>> Why couldn't one of the old pci id's be reused ?
Yes, old pci id's could be reused, and people have done just that. We
thought a new PCI ID would minimize confusion with cards that have already
been deployed.
>>
>> How will the subvendor/subid be enforced ?
Subvendor and Subid are managed just like any other PCI card with or
without a FPGA.
>>
>> Is the current security manager patchset smart enough to save the board from being bricked when a user doesn't look beyond the pci id ?
>
> Yes - the security manager is invoked based of DFL feature ID and revision, and the functionality is differentiated based on the same information.
>
>>
>> What happens if a board uses this device id but doesn't have a max10 to do the update ?
If a board doesn't have a max10, then there will be no DFH for a max10 in
the board's DFLs. Presumeably, the board would need some update process,
and an approprate DFH would be in that board's DFL.
>>
>> Tom
>>
>>> +
>>> Location of DFLs on a PCI Device
>>> ================================
>>> The original method for finding a DFL on a PCI device assumed the start of the
>>
>
>
On 3/3/22 14:04, Tom Rix wrote:
>
> On 3/2/22 4:35 PM, [email protected] wrote:
>> From: Matthew Gerlach <[email protected]>
>>
>> Add documentation on identifying FPGA based PCI cards prompted
>> by discussion on the [email protected] mailing list.
>>
>> Signed-off-by: Matthew Gerlach <[email protected]>
>> ---
>> v2: Introduced in v2.
>> ---
>> Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
>> index ef9eec71f6f3..5fb2ca8e76d7 100644
>> --- a/Documentation/fpga/dfl.rst
>> +++ b/Documentation/fpga/dfl.rst
>> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver with matched feature id.
>> FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
>> could be a reference.
>> +PCI Device Identification
>> +================================
>> +Since FPGA based PCI cards can be reconfigured to a perform a completely
>> +new function at runtime, properly identifying such cards and binding the
>> +correct driver can be challenging. In many use cases, deployed FPGA based
>> +PCI cards are essentially static and the PCI Product ID and Vendor ID pair
>> +is sufficient to identify the card. The DFL framework helps with the
>> +dynamic case of deployed FPGA cards changing at run time by providing
>> +more detailed information about card discoverable at runtime.
>> +
>> +At one level, the DFL on a PCI card describes the function of the card.
>> +However, the same DFL could be instantiated on different physical cards.
>> +Conversely, different DFLs could be instantiated on the same physical card.
>> +Practical management of a cloud containing a heterogeneous set of such cards
>> +requires a PCI level of card identification. While the PCI Product ID and
>> +Vendor ID may be sufficient to bind the dfl-pci driver, it is expected
>> +that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem
>> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for
>> +more granular information about the board.
>
> This describes a bit more of the problem, it should describe it wrt ofs dev id. The introduction of the ofs dev should be explicitly called out as a generic pci id.
>
> Why couldn't one of the old pci id's be reused ?
>
> How will the subvendor/subid be enforced ?
>
> Is the current security manager patchset smart enough to save the board from being bricked when a user doesn't look beyond the pci id ?
Yes - the security manager is invoked based of DFL feature ID and revision, and the functionality is differentiated based on the same information.
>
> What happens if a board uses this device id but doesn't have a max10 to do the update ?
>
> Tom
>
>> +
>> Location of DFLs on a PCI Device
>> ================================
>> The original method for finding a DFL on a PCI device assumed the start of the
>
> Subject: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification
> documentation
>
> From: Matthew Gerlach <[email protected]>
>
> Add documentation on identifying FPGA based PCI cards prompted
> by discussion on the [email protected] mailing list.
>
> Signed-off-by: Matthew Gerlach <[email protected]>
> ---
> v2: Introduced in v2.
> ---
> Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> index ef9eec71f6f3..5fb2ca8e76d7 100644
> --- a/Documentation/fpga/dfl.rst
> +++ b/Documentation/fpga/dfl.rst
> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver
> with matched feature id.
> FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c)
> could be a reference.
>
> +PCI Device Identification
> +================================
> +Since FPGA based PCI cards can be reconfigured to a perform a completely
> +new function at runtime, properly identifying such cards and binding the
> +correct driver can be challenging. In many use cases, deployed FPGA based
> +PCI cards are essentially static and the PCI Product ID and Vendor ID pair
> +is sufficient to identify the card. The DFL framework helps with the
> +dynamic case of deployed FPGA cards changing at run time by providing
> +more detailed information about card discoverable at runtime.
> +
> +At one level, the DFL on a PCI card describes the function of the card.
> +However, the same DFL could be instantiated on different physical cards.
> +Conversely, different DFLs could be instantiated on the same physical card.
> +Practical management of a cloud containing a heterogeneous set of such cards
> +requires a PCI level of card identification. While the PCI Product ID and
> +Vendor ID may be sufficient to bind the dfl-pci driver, it is expected
> +that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem
> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for
> +more granular information about the board.
I think PCI Device/Card Identification is out of scope of DFL. DFL is another
level concept, it can't help to identify which card it is. There is no additional
requirement to users, they can choose any method they want, and they
don't have to reuse dfl-pci for their own cards.
> +
> Location of DFLs on a PCI Device
> ================================
> The original method for finding a DFL on a PCI device assumed the start of the
> --
> 2.25.1
On 3/4/22 10:30 AM, [email protected] wrote:
>
>
> On Fri, 4 Mar 2022, Russ Weight wrote:
>
>>
>>
>> On 3/3/22 14:04, Tom Rix wrote:
>>>
>>> On 3/2/22 4:35 PM, [email protected] wrote:
>>>> From: Matthew Gerlach <[email protected]>
>>>>
>>>> Add documentation on identifying FPGA based PCI cards prompted
>>>> by discussion on the [email protected] mailing list.
>>>>
>>>> Signed-off-by: Matthew Gerlach <[email protected]>
>>>> ---
>>>> v2: Introduced in v2.
>>>> ---
>>>> Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++
>>>> 1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
>>>> index ef9eec71f6f3..5fb2ca8e76d7 100644
>>>> --- a/Documentation/fpga/dfl.rst
>>>> +++ b/Documentation/fpga/dfl.rst
>>>> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature
>>>> driver with matched feature id.
>>>> FME Partial Reconfiguration Sub Feature driver (see
>>>> drivers/fpga/dfl-fme-pr.c)
>>>> could be a reference.
>>>> +PCI Device Identification
>>>> +================================
>>>> +Since FPGA based PCI cards can be reconfigured to a perform a
>>>> completely
>>>> +new function at runtime, properly identifying such cards and
>>>> binding the
>>>> +correct driver can be challenging. In many use cases, deployed
>>>> FPGA based
>>>> +PCI cards are essentially static and the PCI Product ID and Vendor
>>>> ID pair
>>>> +is sufficient to identify the card. The DFL framework helps with the
>>>> +dynamic case of deployed FPGA cards changing at run time by providing
>>>> +more detailed information about card discoverable at runtime.
>>>> +
>>>> +At one level, the DFL on a PCI card describes the function of the
>>>> card.
>>>> +However, the same DFL could be instantiated on different physical
>>>> cards.
>>>> +Conversely, different DFLs could be instantiated on the same
>>>> physical card.
>>>> +Practical management of a cloud containing a heterogeneous set of
>>>> such cards
>>>> +requires a PCI level of card identification. While the PCI Product
>>>> ID and
>>>> +Vendor ID may be sufficient to bind the dfl-pci driver, it is
>>>> expected
>>>> +that FPGA PCI cards would advertise suitable Subsystem ID and
>>>> Subsystem
>>>> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for
>>>> +more granular information about the board.
>>>
>>> This describes a bit more of the problem, it should describe it wrt
>>> ofs dev id. The introduction of the ofs dev should be explicitly
>>> called out as a generic pci id.
>
> The problem I'm describing exists for all FPGA based PCI cards; so I
> am purposely trying to be abstract as much as possible.
>
>>>
>>> Why couldn't one of the old pci id's be reused ?
>
> Yes, old pci id's could be reused, and people have done just that. We
> thought a new PCI ID would minimize confusion with cards that have
> already been deployed.
>
>>>
>>> How will the subvendor/subid be enforced ?
>
> Subvendor and Subid are managed just like any other PCI card with or
> without a FPGA.
Reviewing how the kernel uses subvendor and subsystem shows it is not
widely used.
And when it is, it is used to isolate small variations or hw problems in
the device, not completely unique cards
There are very few subsytem/subvendor's in pci_id.h, the usual case
seems to be hardcoded hex.
So there is no enforcement.
I can not see how this generic id would not be abused by vendors nor how
it would not be confusing to the end users.
Tom
>
>>>
>>> Is the current security manager patchset smart enough to save the
>>> board from being bricked when a user doesn't look beyond the pci id ?
>>
>> Yes - the security manager is invoked based of DFL feature ID and
>> revision, and the functionality is differentiated based on the same
>> information.
>>
>>>
>>> What happens if a board uses this device id but doesn't have a max10
>>> to do the update ?
>
> If a board doesn't have a max10, then there will be no DFH for a max10
> in the board's DFLs. Presumeably, the board would need some update
> process, and an approprate DFH would be in that board's DFL.
>
>>>
>>> Tom
>>>
>>>> +
>>>> Location of DFLs on a PCI Device
>>>> ================================
>>>> The original method for finding a DFL on a PCI device assumed the
>>>> start of the
>>>
>>
>>