Netdev List
 help / color / mirror / Atom feed
From: <alejandro.lucero-palau@amd.com>
To: <linux-cxl@vger.kernel.org>, <netdev@vger.kernel.org>,
	<edward.cree@amd.com>, <davem@davemloft.net>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <edumazet@google.com>,
	<dave.jiang@intel.com>
Cc: Alejandro Lucero <alucerop@amd.com>
Subject: [RFC 0/2] Type2 multipf support
Date: Fri, 21 Aug 2026 16:51:32 +0100	[thread overview]
Message-ID: <20260821155134.260053-1-alejandro.lucero-palau@amd.com> (raw)

From: Alejandro Lucero <alucerop@amd.com>

Commit message of first patch explains why this is needed but I want to
add some comments here.

First, the final Type2 basic support was possible once Dan Williams and
I reached an agreement on how to solve the potential unwinding spenarios
linked to a cxl memdev object. The actions triggering this unwinding are:

 - User space unbinding the cxl mem device from the cxl mem driver.
 - User space removing cxl_acpi module.
 - User space unbinding Type2/accelerator pci device from its driver.
 - User space removing Type2/accelerator driver.

The last two trigger the unwinding from the Type2/accelerator driver
exit path, while the first two start the unwinding which in turn invoke
the Type2 driver release from its pci device.

In any case, the decission was to release the Type2 driver always
instead of a degraded functionality if CXL.mem is only part of the full
functionality. This needs to be extended to other non-PF0 PFs, so all
the scenarios listed above ending up releasing those other PFs as well
from their drivers.

This needs to link a memdev to those non-PF0 PFs, and invoke those PFs
release from their drivers when unwinding. This is not complicated per
se but the devil is in the potential race conditions between the
linking/unlinking and the memdev release. I think it does only require
to keep a reference to the memdev device for the time the
linking/unlinking happens, but maybe there are corner cases I did not
think about. I have tested it with real hardware advertising two PFs and
under all the scenarios listed, but stressing this requires another
framework, likely under qemu or adding a new cxl test set.

FWIW, using vanilla 7.2 as cxl next has not the sfc changes yet.

Alejandro Lucero (2):
  cxl/memdev: add support for mutipf device
  sfc: add multipf support

 drivers/cxl/core/memdev.c          | 122 +++++++++++++++++++++++++++++
 drivers/cxl/cxlmem.h               |   1 +
 drivers/net/ethernet/sfc/efx_cxl.c | 106 +++++++++++++++++++++++--
 include/cxl/cxl.h                  |   4 +
 4 files changed, 227 insertions(+), 6 deletions(-)


base-commit: 818bebeb63dd6bf5f4e07e145f6cdbace520a34c
-- 
2.34.1


             reply	other threads:[~2026-08-21 14:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 15:51 alejandro.lucero-palau [this message]
2026-08-21 15:51 ` [RFC 1/2] cxl/memdev: add support for mutipf device alejandro.lucero-palau
2026-08-24  8:33   ` Richard Cheng
2026-08-21 15:51 ` [RFC 2/2] sfc: add multipf support alejandro.lucero-palau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260821155134.260053-1-alejandro.lucero-palau@amd.com \
    --to=alejandro.lucero-palau@amd.com \
    --cc=alucerop@amd.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=kuba@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox