[v5,00/27] cxl: add type2 device basic support

Message

Lucero Palau, Alejandro Nov. 18, 2024, 4:44 p.m. UTC

From: Alejandro Lucero <[e-mail]>

v5 changes:

 - Fix SFC configuration based on kernel CXL configuration
 - Add subset check for capabilities.
 - fix region creation when HDM decoders programmed by firmware/BIOS (Ben
   Cheatham)
 - Add option for creating dax region based on driver decission (Ben
   Cheatham)
 - Using sfc probe_data struct for keeping sfc cxl data

v4 changes:
  
 - Use bitmap for capabilities new field (Jonathan Cameron)

 - Use cxl_mem attributes for sysfs based on device type (Dave Jian)

 - Add conditional cxl sfc compilation relying on kernel CXL config (kernel test robot)

 - Add sfc changes in different patches for facilitating backport (Jonathan Cameron)

 - Remove patch for dealing with cxl modules dependencies and using sfc kconfig plus
   MODULE_SOFTDEP instead.

v3 changes:

 - cxl_dev_state not defined as opaque but only manipulated by accel drivers
   through accessors.

 - accessors names not identified as only for accel drivers.

 - move pci code from pci driver (drivers/cxl/pci.c) to generic pci code
   (drivers/cxl/core/pci.c).

 - capabilities field from u8 to u32 and initialised by CXL regs discovering
   code.

 - add capabilities check and removing current check by CXL regs discovering
   code.

 - Not fail if CXL Device Registers not found. Not mandatory for Type2.

 - add timeout in acquire_endpoint for solving a race with the endpoint port
   creation.

 - handle EPROBE_DEFER by sfc driver.

 - Limiting interleave ways to 1 for accel driver HPA/DPA requests.

 - factoring out interleave ways and granularity helpers from type2 region
   creation patch.

 - restricting region_creation for type2 to one endpoint decoder.

 - add accessor for release_resource.

 - handle errors and errors messages properly.


v2 changes:

I have removed the introduction about the concerns with BIOS/UEFI after the
discussion leading to confirm the need of the functionality implemented, at
least is some scenarios.

There are two main changes from the RFC:

1) Following concerns about drivers using CXL core without restrictions, the CXL
struct to work with is opaque to those drivers, therefore functions are
implemented for modifying or reading those structs indirectly.

2) The driver for using the added functionality is not a test driver but a real
one: the SFC ethernet network driver. It uses the CXL region mapped for PIO
buffers instead of regions inside PCIe BARs.



RFC:

Current CXL kernel code is focused on supporting Type3 CXL devices, aka memory
expanders. Type2 CXL devices, aka device accelerators, share some functionalities
but require some special handling.

First of all, Type2 are by definition specific to drivers doing something and not just
a memory expander, so it is expected to work with the CXL specifics. This implies the CXL
setup needs to be done by such a driver instead of by a generic CXL PCI driver
as for memory expanders. Most of such setup needs to use current CXL core code
and therefore needs to be accessible to those vendor drivers. This is accomplished
exporting opaque CXL structs and adding and exporting functions for working with
those structs indirectly.

Some of the patches are based on a patchset sent by Dan Williams [1] which was just
partially integrated, most related to making things ready for Type2 but none
related to specific Type2 support. Those patches based on Dan´s work have Dan´s
signing as co-developer, and a link to the original patch.

A final note about CXL.cache is needed. This patchset does not cover it at all,
although the emulated Type2 device advertises it. From the kernel point of view
supporting CXL.cache will imply to be sure the CXL path supports what the Type2
device needs. A device accelerator will likely be connected to a Root Switch,
but other configurations can not be discarded. Therefore the kernel will need to
check not just HPA, DPA, interleave and granularity, but also the available
CXL.cache support and resources in each switch in the CXL path to the Type2
device. I expect to contribute to this support in the following months, and
it would be good to discuss about it when possible.

[1] https://lore.kernel.org/linux-cxl/[e-mail]/T/

Alejandro Lucero (27):
  cxl: add type2 device basic support
  sfc: add cxl support using new CXL API
  cxl: add capabilities field to cxl_dev_state and cxl_port
  cxl/pci: add check for validating capabilities
  cxl: move pci generic code
  cxl: add function for type2 cxl regs setup
  sfc: use cxl api for regs setup and checking
  cxl: add functions for resource request/release by a driver
  sfc: request cxl ram resource
  cxl: harden resource_contains checks to handle zero size resources
  cxl: add function for setting media ready by a driver
  sfc: set cxl media ready
  cxl: prepare memdev creation for type2
  sfc: create type2 cxl memdev
  cxl: define a driver interface for HPA free space enumeration
  sfc: obtain root decoder with enough HPA free space
  cxl: define a driver interface for DPA allocation
  sfc: get endpoint decoder
  cxl: make region type based on endpoint type
  cxl/region: factor out interleave ways setup
  cxl/region: factor out interleave granularity setup
  cxl: allow region creation by type2 drivers
  sfc: create cxl region
  cxl: add region flag for precluding a device memory to be used for dax
  sfc: specify avoid dax when cxl region is created
  cxl: add function for obtaining params from a region
  sfc: support pio mapping based on cxl

 drivers/cxl/core/cdat.c               |   3 +
 drivers/cxl/core/hdm.c                | 160 ++++++++--
 drivers/cxl/core/memdev.c             | 123 +++++++-
 drivers/cxl/core/pci.c                | 132 ++++++++
 drivers/cxl/core/port.c               |  11 +-
 drivers/cxl/core/region.c             | 414 ++++++++++++++++++++++----
 drivers/cxl/core/regs.c               |  30 +-
 drivers/cxl/cxl.h                     |  17 +-
 drivers/cxl/cxlmem.h                  |   5 +
 drivers/cxl/cxlpci.h                  |  19 +-
 drivers/cxl/mem.c                     |  25 +-
 drivers/cxl/pci.c                     |  99 +++---
 drivers/cxl/port.c                    |   5 +-
 drivers/net/ethernet/sfc/Kconfig      |   7 +
 drivers/net/ethernet/sfc/Makefile     |   1 +
 drivers/net/ethernet/sfc/ef10.c       |  49 ++-
 drivers/net/ethernet/sfc/efx.c        |  24 +-
 drivers/net/ethernet/sfc/efx_cxl.c    | 181 +++++++++++
 drivers/net/ethernet/sfc/efx_cxl.h    |  28 ++
 drivers/net/ethernet/sfc/mcdi_pcol.h  |  12 +
 drivers/net/ethernet/sfc/net_driver.h |  12 +
 drivers/net/ethernet/sfc/nic.h        |   3 +
 include/cxl/cxl.h                     |  82 +++++
 include/cxl/pci.h                     |  23 ++
 24 files changed, 1269 insertions(+), 196 deletions(-)
 create mode 100644 drivers/net/ethernet/sfc/efx_cxl.c
 create mode 100644 drivers/net/ethernet/sfc/efx_cxl.h
 create mode 100644 include/cxl/cxl.h
 create mode 100644 include/cxl/pci.h

Comments

Alison Schofield Nov. 21, 2024, 3:33 a.m. UTC | #1

On Mon, Nov 18, 2024 at 04:44:07PM +0000, [e-mail] wrote:
> From: Alejandro Lucero <[e-mail]>
> 
> v5 changes:

Hi Alejandro -

What is the base commit for this set?  (I'm trying to apply it)

In future revs please include the base commit. I typically get it
by setting the upstream branch and then doing --base="auto" when
formatting the patches.

Thanks!
Alison

..snip

> 
>

Alejandro Lucero Palau Nov. 21, 2024, 9:27 a.m. UTC | #2

On 11/21/24 03:33, Alison Schofield wrote:
> On Mon, Nov 18, 2024 at 04:44:07PM +0000, [e-mail] wrote:
>> From: Alejandro Lucero <[e-mail]>
>>
>> v5 changes:
> Hi Alejandro -


Hi Allison,


> What is the base commit for this set?  (I'm trying to apply it)


I'm not using the CXL tree but Linus one, and using 6.12-rc7


> In future revs please include the base commit. I typically get it
> by setting the upstream branch and then doing --base="auto" when
> formatting the patches.


Apologies for the inconveniences. I'll do so for v6, which will use 6.13

Thanks


>
> Thanks!
> Alison
>
> ..snip
>
>>