From: "Lucero Palau, Alejandro" <alejandro.lucero-palau@amd.com>
To: Dave Jiang <dave.jiang@intel.com>,
Richard Cheng <icheng@nvidia.com>,
jic23@kernel.org, dave@stgolabs.net, alison.schofield@intel.com,
vishal.l.verma@intel.com, iweiny@kernel.org,
ming.li@zohomail.com
Cc: kaihengf@nvidia.com, kobak@nvidia.com, newtonl@nvidia.com,
kristinc@nvidia.com, linux-cxl@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/3] cxl: Provide explicit RAM region creation for Type-2 providers
Date: Wed, 14 Oct 2026 18:29:58 +0100 [thread overview]
Message-ID: <89cdd4e8-31bb-4047-bd36-0ff5d7ff4c39@amd.com> (raw)
In-Reply-To: <ccfb14ff-989c-44c5-96be-a092a5c0fad9@intel.com>
On 14/10/2026 18:16, Dave Jiang wrote:
>
> On 10/14/26 9:35 AM, Lucero Palau, Alejandro wrote:
>> On 14/10/2026 17:23, Dave Jiang wrote:
>>> On 10/14/26 8:34 AM, Lucero Palau, Alejandro wrote:
>>>> On 07/10/2026 10:05, Richard Cheng wrote:
>>>>> A Type-2 provider uses devm_cxl_probe_mem() to register its memdev
>>>>> and obtain an HPA range. This requires an existing committed region,
>>>>> so registration fails when firmware has not configured one.
>>>>>
>>>>> Firmware may provide a suitable CFMWS window without programming a
>>>>> region.
>>>> Hi Richard,
>>>>
>>>>
>>>> FWIW, I unsuccessfully tried to explain this possibility to "BIOS people". The fact is, nowadays for AMD and I think for Intel as well, if there is no CXL device detected with CXL.mem enabled, the BIOS will neither set HDMs nor there will be a CFMWS.
>>> Hmmmm....don't they have to reserve CFMWS for hotplug?
>>
>> I have to admit I'm a bit lost with hotplugging and CXL needs, and not real experience with hot plug devices at all, but in my mind hotplugging allows a great flexibility which is counterintuitive if you need to know before hand which devices are going to be hot plugged ..., regarding CXL, how a CFMWS can be created without having that information? Maybe there is something in the specs about this and I did not pay attention.
>>
> I believe BIOS needs to set aside a range of HPA via CFMWS to allow for hot plugged devices.
>
>> What do you think about my other concern below?
>>
>>
>>> DJ
>>>
>>>>
>>>>> Hot-added devices can have the same requirement. A provider
>>>>> needs its endpoint topology established before deciding when to
>>>>> create a region and how much memory to map.
>>>> Another unsuccessfully discussion was to avoid BIOS setting HDMs at hotplug time as this could race with host dynamic regions creation.
>>>>
> The BIOS does not touch device when hot plugged I believe. It's all OS native handled.
If this is the kernel expectation and I'm the only one concerned with
BIOSes respecting it, nothing more to be discussed.
Thanks,
Alejandro.
>>>> I'm commenting these two things here for maybe having a community/kernel discussion with the goal of defining what BIOSes should do and mostly what they should not do if they want to be compatible with kernel expectations.
>>>>
>>>>
prev parent reply other threads:[~2026-10-14 17:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 9:05 [RFC PATCH v2 0/3] cxl: Provide explicit RAM region creation for Type-2 providers Richard Cheng
2026-10-07 9:05 ` [RFC PATCH v2 1/3] cxl/mem: Separate provider registration from region attachment Richard Cheng
2026-10-14 17:17 ` Lucero Palau, Alejandro
2026-10-07 9:05 ` [RFC PATCH v2 2/3] cxl/mem: Add explicit RAM region creation for providers Richard Cheng
2026-10-07 9:05 ` [RFC PATCH v2 3/3] cxl/test: Exercise explicit Type-2 RAM region creation Richard Cheng
2026-10-09 18:34 ` Dave Jiang
2026-10-14 15:34 ` [RFC PATCH v2 0/3] cxl: Provide explicit RAM region creation for Type-2 providers Lucero Palau, Alejandro
2026-10-14 16:23 ` Dave Jiang
2026-10-14 16:35 ` Lucero Palau, Alejandro
2026-10-14 17:16 ` Dave Jiang
2026-10-14 17:29 ` Lucero Palau, Alejandro [this message]
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=89cdd4e8-31bb-4047-bd36-0ff5d7ff4c39@amd.com \
--to=alejandro.lucero-palau@amd.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=icheng@nvidia.com \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kaihengf@nvidia.com \
--cc=kobak@nvidia.com \
--cc=kristinc@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=newtonl@nvidia.com \
--cc=vishal.l.verma@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.