linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] DOE usage with pcie/portdrv
@ 2022-05-03 15:34 Jonathan Cameron
  2022-05-03 15:34 ` [RFC PATCH 1/1] pcie/portdrv: Hack in DOE and CDAT support Jonathan Cameron
  2022-05-06 22:40 ` [RFC PATCH 0/1] DOE usage with pcie/portdrv Dan Williams
  0 siblings, 2 replies; 22+ messages in thread
From: Jonathan Cameron @ 2022-05-03 15:34 UTC (permalink / raw)
  To: linuxarm, ira.weiny, Linux PCI, linux-cxl, Dan Williams

So far, we have been considering Data Object Exchange (DOE) mailboxes only
on EPs (CXL type 3 devices).
CXL CDAT (technically CXL Table Query Protocol but lets just call it CDAT)
  https://lore.kernel.org/linux-cxl/20220414203237.2198665-1-ira.weiny@intel.com
CMA/SPDM support
  https://lore.kernel.org/linux-cxl/20220303135905.10420-1-Jonathan.Cameron@huawei.com/

However, a number of DOE protocols apply to switch (and root) ports.
DOE instances supporting CDAT occur on switch upstream ports as well as EPs.

DOE instances supporting CMA may occur in root ports, upstream switch ports,
downstream switch ports and EPs (including multiple functions where relevant).

The intent of this RFC is to discuss how to actually implement such support.
The attached patch is a really rough PoC for CDAT on upstream switch ports
done by adding a new pcie_port_service_driver.  This is different from the
proposed auxiliary device used for CXL type 3 devices (for now).

So open questions:

1. Granularity. Should we do a driver per group of protocols that may
   be collocated, or one per DOE instance. For now, we might be looking
   at CDAT as done for this PoC, and CMA/IDE.
2. Use of a pcie_port_service_driver a reasonable way to do this?
3. Service provision. It is likely that all of the protocols defined
   above will be used as part of activities that span multiple devices.
   a) CDAT used to establish latencies and bandwidth between host CPU
      and memory on a CXL type 3 device beyond one or more CXL switches.
   b) CMA.  Might just be used to provide simple device attestation
      and potentially lock out the upstream port above a switch if the
      switch does not pass attestation.  Many many other uses possible...
   c) Secure CMA / IDE. Likely to be used to set up link IDE.  What
      this will look like is a question I've not really started
      thinking about yet.

   So how do we support this?  If nothing else we need to make sure
   the drivers for the port don't go away whilst in use.

The patch is a very early PoC just to show it would 'work'...

Note I am keen to not have the discussion around this support delay
Ira's series.

Jonathan Cameron (1):
  pcie/portdrv: Hack in DOE and CDAT support

 drivers/pci/pcie/Kconfig        |   5 ++
 drivers/pci/pcie/Makefile       |   1 +
 drivers/pci/pcie/cdat.c         | 127 ++++++++++++++++++++++++++++++++
 drivers/pci/pcie/portdrv.h      |   9 ++-
 drivers/pci/pcie/portdrv_core.c |  43 ++++++++++-
 drivers/pci/pcie/portdrv_pci.c  |   2 +
 6 files changed, 183 insertions(+), 4 deletions(-)
 create mode 100644 drivers/pci/pcie/cdat.c

-- 
2.32.0


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-05-27  9:39 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-03 15:34 [RFC PATCH 0/1] DOE usage with pcie/portdrv Jonathan Cameron
2022-05-03 15:34 ` [RFC PATCH 1/1] pcie/portdrv: Hack in DOE and CDAT support Jonathan Cameron
2022-05-06 22:40 ` [RFC PATCH 0/1] DOE usage with pcie/portdrv Dan Williams
2022-05-07 10:18   ` Lukas Wunner
2022-05-09  9:48     ` Jonathan Cameron
2022-05-11 19:13       ` Lukas Wunner
2022-05-11 19:19         ` Lukas Wunner
2022-05-11 19:43           ` Dan Williams
2022-05-14 13:55             ` Lukas Wunner
2022-05-16 17:01               ` Dan Williams
2022-05-27  9:39                 ` Lukas Wunner
2022-05-18 13:43               ` Christoph Hellwig
2022-05-18 15:08                 ` Dan Williams
2022-05-20  5:42                 ` Lukas Wunner
2022-05-20 15:37                   ` Dan Williams
2022-05-20 15:42                     ` Chuck Lever III
2022-05-11 19:42         ` Dan Williams
2022-05-11 20:22           ` Hindman, Gavin
2022-05-11 21:04             ` Dan Williams
2022-05-14 13:31           ` Lukas Wunner
2022-05-16 16:53             ` Dan Williams
2022-05-09  9:33   ` Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).