Message-ID: <5d59b03d-12be-4bc5-b7e3-055486fc0866@amd.com>
Date: Wed, 28 Jan 2026 16:19:59 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: dan.j.williams@...el.com,
 "Koralahalli Channabasappa, Smita" <skoralah@....com>,
 Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
 linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
 nvdimm@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
 linux-pm@...r.kernel.org
Cc: Ard Biesheuvel <ardb@...nel.org>,
 Alison Schofield <alison.schofield@...el.com>,
 Vishal Verma <vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Yazen Ghannam <yazen.ghannam@....com>, Dave Jiang <dave.jiang@...el.com>,
 Davidlohr Bueso <dave@...olabs.net>, Matthew Wilcox <willy@...radead.org>,
 Jan Kara <jack@...e.cz>, "Rafael J . Wysocki" <rafael@...nel.org>,
 Len Brown <len.brown@...el.com>, Pavel Machek <pavel@...nel.org>,
 Li Ming <ming.li@...omail.com>, Jeff Johnson
 <jeff.johnson@....qualcomm.com>, Ying Huang <huang.ying.caritas@...il.com>,
 Yao Xingtao <yaoxt.fnst@...itsu.com>, Peter Zijlstra <peterz@...radead.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Nathan Fontenot <nathan.fontenot@....com>,
 Terry Bowman <terry.bowman@....com>, Robert Richter <rrichter@....com>,
 Benjamin Cheatham <benjamin.cheatham@....com>,
 Zhijian Li <lizhijian@...itsu.com>, Borislav Petkov <bp@...en8.de>,
 Tomasz Wolski <tomasz.wolski@...itsu.com>
Subject: Re: [PATCH v5 6/7] dax/hmem, cxl: Defer and resolve ownership of Soft
 Reserved memory ranges


On 1/27/26 23:41, dan.j.williams@...el.com wrote:
> Alejandro Lucero Palau wrote:
> [..]
>> I will take a look at this presentation, but I think there could be
>> another option where accelerators information is obtained during pci
>> enumeration by the kernel and using this information by this
>> functionality skipping those ranges allocated to them. Forcing them to
>> be compiled with the kernel would go against what distributions
>> currently and widely do with initramfs. Not sure if some current "early"
>> stubs could be used for this though but the information needs to be
>> recollected before this code does the checks.
> The simple path is "do not use EFI_MEMORY_SP for accelerator memory".


Sure. That is what I hope our device will end up having ... since 
neither hmem nor dax is an option for us.


> However, if the accelerator wants to publish memory as EFI_MEMORY_SP
> then it needs to coordinate with the kernel's default behavior somehow.


I think some Type2 drivers could be happy with dax and therefore using 
EFI_MEMORY_SP, so yes, that is what I meant: there is another option 
instead of forcing drivers to be present at the time of this decision. 
If someone reading is working on Type2 drivers and see this 
suitable/required, please tell. I'll be interested in doing it or helping.


> That means expanding the list of drivers that dax_hmem needs to await
> before it can make a determination, or teaching dax_hmem to look for a
> secondary indication that it should never fall back to the default
> behavior.


I think waiting could be problematic as some Type2 drivers could not be 
automatically load. It looks like if a CXL region is not backing the 
Type2 CXL.mem completely should not impact dax devices and cxl regions 
maybe being used at Type2 driver probe. Would a warning be enough?


>
> Talk to your AMD peers Paul and Rajneesh about their needs. I took it on
> faith that the use case was required.


After reading that presentation, I think this is a different subject. 
Assuming case 1 there is what you have in mind, and if I understand it 
properly, that could be useful for companies owning the full platform, 
but not sure adding a specific acpi driver per device makes sense for 
less-powerful vendors. Anyway, I will talk with them as the memory 
allocation part which seems to be one thing to do by those acpi drivers 
is interesting.


Thank you

Powered by blists - more mailing lists