Re: [PATCH v5 6/7] dax/hmem, cxl: Defer and resolve ownership of Soft Reserved memory ranges

[Alejandro Lucero Palau <alucerop@amd.com>]

On 1/27/26 23:41, dan.j.williams@intel.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