Re: [RFC PATCH 0/3] cxl: Auto-create a region for Type-2 memdev attach

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 28 Sep 2026 05:37:45 +0000
Ankit Agrawal <ankita@nvidia.com> wrote:

> >> > 
> >> > 
> >> > <snip>  
> >> > > I think you are right that this RFC doesn't currently have a production platform
> >> > > where the system FW publishes a Type-2 CFMWS but leaves the EP decoder
> >> > > uncommitted.
> >> > > 
> >> > > However, the config appears to be permitted by the CXL model. A CFMWS describes
> >> > > a FW-established root HPA window and the restrictions governing its use,
> >> > > including Type-2 v.s. Type-3 and volatile v.s. PMEM. The CFMWS def also
> >> > > describes OSPM assigning HPA ranges from those windows to discovered CXL.mem
> >> > > devices [1].    
> >> > 
> >> > 
> >> > Right. I'm not saying this should not be supported, just pointing out the
> >> > use case does not make sense with current BIOS functionality. I think BIOS
> >> > will/could support a config option for just leaving a Type2 HDM uncommitted,
> >> > but then why the kernel should do the same a default BIOS config would do?
> >> >    
> >> 
> >> Agreed. The kernel shouldn't recreate the config that BIOS would normally provide.  
> >
> > I'm a bit lost. Both BIOS doing nothing beyond cfmws as a design decision and
> > hotplug (where bios isn't in the loop) require this sort of flow.
> >
> > Sure both might not be what you happen to have today but they are both
> > very much real usecases!
> >
> > Jonathan  
> 
> So, can we consider doing both in 2 phases..
> 1. Autocreate a default region that is sized to the device's DVSEC reported
> DPA capacity when the platform signals it (applicable only to CFMWS present
> Type-2 CXL.mem-capable, decoder uncommitted case?). I suppose this could
> cover the use cases suggested by Jonathan?
> 2. Let the driver explicitly replace/override it with a different sized region
> once bound per its own policy.

I don't see a reason for 1.  The bios has to have provided a CFMWS that will
work or option 2 will fail - if it supports hotplug or indeed doesn't want to
do config of devices on cold plug it just provides 'enough space'.  Whether it
does that by hard coded big number, bios menu option or otherwise doesn't
matter to us.

But in general a driver should bind before we create anything (assuming we
are in a host OS managed flow).  Why would we want to do anything before that
as we have no idea if a driver will ever bind - or if there is flexibility
in size exposed that can't be known until driver bind.

> 
> >> And that's why I think we should move region createion out of devm_cxl_probe_mem().
> >> That helper should discover and attach to an already committed region.
> >> 
> >> If FW leaves the decoders unconfigured intentionally , a driver may explicitly request a region
> >> and provide the size it needs.
> >> 
> >> In my mind the new model should be
> >> - FW-committed config is only discovered and attached
> >> - an uncommitted config remains untouched unless a driver explicitly requests it
> >> - CXL core supplieds the allocation, validation, programming, accounting and teardown mechnism
> >> - the requesting driver owns the policy and the use of the region  
> 
> Is there going to be a custom non-default size to commit be communicated
> to the vendor driver? AIU currently the size is only driver-internal constant.

Given it is potentially a contended resource, we may need a way to clamp
the maximum a particular instances is allowed to request. For now maybe
first come, first served is good enough? No idea. 

Jonathan

> 
> Thanks
> Ankit Agrawal