Message-ID: <07a0cd77a61358cfb6e436da60fb5f644201b52c.camel@kernel.org>
Date: Tue, 02 Dec 2025 00:49:36 -0800
From: PJ Waskiewicz <ppwaskie@...nel.org>
To: Alejandro Lucero Palau <alucerop@....com>,
 alejandro.lucero-palau@....com, 	linux-cxl@...r.kernel.org,
 netdev@...r.kernel.org, dan.j.williams@...el.com, 	edward.cree@....com,
 davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	edumazet@...gle.com, dave.jiang@...el.com
Cc: Martin Habets <habetsm.xilinx@...il.com>, Edward Cree
	 <ecree.xilinx@...il.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
 Ben Cheatham <benjamin.cheatham@....com>
Subject: Re: [PATCH v21 15/23] sfc: get endpoint decoder

Hi Alejandro,

On Thu, 2025-11-27 at 09:08 +0000, Alejandro Lucero Palau wrote:
> > 
> > TL;DR: if your device you're testing with presents the CXL.mem
> > region
> > as EFI_RESERVED_TYPE, I don't see how these patches are working.
> > Unless you're doing something extra outside of the patches, which
> > isn't
> > obvious to me.
> 
> 
> Yes, sorry, that is the case. I'm applying some dirty changes to
> these 
> patches for testing with my current testing devices, including the
> BIOS 
> and the Host.
> 

Well, this is basically the issue.

You are proposing these patches to support Type 2 devices, and use the
X4 with SFC as the vehicle.  But out of the box, following the same
flow, my driver for my (proprietary) device can't match the behavior. 
If you're having to make modifications to these patches to work with
your device, even if it's to work around a weird platform or BIOS, then
these patches can't be considered as-is.

I have two main platforms in use for development.  One is an Intel
Granite Rapids, one is an AMD Turin.  I've got production SKU's and
CRB's, so I have a cross-section of BIOS's.  All of them behave the
exact same way with these patches.  I do have a BIOS that is doing the
right thing from what I can tell (tracing with a bus analyzer, and also
ILA taps).

CXL Type 2 device support is desparately needed.  I'm happy you've been
championing this to get it merged.  I'm also very committed to helping
test, modify, etc.  So please don't be discouraged.

I'm also one who's dealt with internal pressures from a company to get
something working upstream.  But honestly, upstream work doesn't align
with corporate or company calendars.  Been there, done that, hasn't
gotten easier.  The kernel can't take a patchset that doesn't work at
face value.  It's unfortunately as simple as that.  So let's figure out
how to get it working out of the box with the patches.

> 
> > > 
> > > FWIW, last year in Vienna I raised the concern of the kernel
> > > doing
> > > exactly what you are witnessing, and I proposed having a way for
> > > taking
> > > the device/memory from DAX but I was told unanimously that was
> > > not
> > > necessary and if the BIOS did the wrong thing, not fixing that in
> > > the
> > > kernel. In hindsight I would say this conflict was not well
> > > understood
> > > then (me included) with all the details, so maybe it is time to
> > > have
> > > this capacity, maybe from user space or maybe specific kernel
> > > param
> > > triggering the device passing from DAX.
> > I do recall this.  Unfortunately I brought up similar concerns way
> > back
> > in Dublin in 2021 regarding all of this flow well before 2.0-
> > capable
> > hosts arrived.  I think I started asking the questions way too
> > early,
> > since this was of little to no concern at the time (nor was Type2
> > device support).
> 
> 
> Maybe we can make the case now. I'll seize LPC to discuss this
> further. 
> Will you be there?

Yep.  I'll be there, as will Dan.  We definitely need to find some time
and chat.


Cheers,
-PJ

Powered by blists - more mailing lists