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

[Ankit Agrawal]

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

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

Thanks
Ankit Agrawal