| Message ID | 20220303003534.3307971-2-matthew.gerlach@linux.intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add PCIE device IDs for Intel DFL cards | expand |
On 3/2/22 4:35 PM, matthew.gerlach@linux.intel.com wrote: > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > Add documentation on identifying FPGA based PCI cards prompted > by discussion on the linux-fpga@vger.kernel.org mailing list. > > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> > --- > 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 3/3/22 14:04, Tom Rix wrote: > > On 3/2/22 4:35 PM, matthew.gerlach@linux.intel.com wrote: >> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >> >> Add documentation on identifying FPGA based PCI cards prompted >> by discussion on the linux-fpga@vger.kernel.org mailing list. >> >> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> >> --- >> 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 >
On Fri, 4 Mar 2022, Russ Weight wrote: > > > On 3/3/22 14:04, Tom Rix wrote: >> >> On 3/2/22 4:35 PM, matthew.gerlach@linux.intel.com wrote: >>> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >>> >>> Add documentation on identifying FPGA based PCI cards prompted >>> by discussion on the linux-fpga@vger.kernel.org mailing list. >>> >>> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> >>> --- >>> 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 >> > >
> Subject: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification > documentation > > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > Add documentation on identifying FPGA based PCI cards prompted > by discussion on the linux-fpga@vger.kernel.org mailing list. > > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> > --- > 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, matthew.gerlach@linux.intel.com 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, matthew.gerlach@linux.intel.com wrote: >>>> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >>>> >>>> Add documentation on identifying FPGA based PCI cards prompted >>>> by discussion on the linux-fpga@vger.kernel.org mailing list. >>>> >>>> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> >>>> --- >>>> 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 >>> >> >>
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