Message-ID: <e1009cde-ee48-478c-a8cf-13762e272ecb@amd.com>
Date: Tue, 2 Dec 2025 09:09:32 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: PJ Waskiewicz <ppwaskie@...nel.org>, 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


On 12/2/25 08:49, PJ Waskiewicz wrote:
> Hi Alejandro,


Hi PJ,


> 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 disagree. From day one I was told our device should not be touched by 
BIOS. If I have no hardware yet doing so it should not be changing the 
specific support I need, something I can easily emulate with QEMU and 
what I have been using in parallel to other specific hardware emulations 
internally.


>
> 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.


Thanks for the kind words.


>
> 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.


Yes, management usually do not understand how kernel upstream effort 
happens, but it is not a relieve to know that ...


I did work on your problem (and I guess not only yours) these last days 
and I'm happy to say I have a solution ready to be shared. It will be in 
v22 what I hope to have ready later today, and it is simple and, I 
think, clean enough to be accepted without too much adjustments. Of 
course, it will depend on how quick reviewing happen and exchanges about 
how to do it if it is not liked follow.

Thank you


>>>> 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