Re: [PATCH v2 2/4] cxl/region: Add region reference in memdev attach

["Lucero Palau, Alejandro" <alejandro.lucero-palau@amd.com>]

On 08/10/2026 22:05, Dave Jiang wrote:
>
> On 10/8/26 11:07 AM, Lucero Palau, Alejandro wrote:


<snip>

>>
>> Dan and I addressed some concerns with "these options" but it is worse after realising now port and region can also suffer from unbinding actions. We contemplated memdev unbinding and that is supported, and acpi module removal as well (all the unwinding is hopefully right for sfc driver removal), but the fact is, current Type2 support is unsound. It is likely good enough with current usage expectations but something to improve/fix.
> Removing the acpi module will also cause the issue I pointed out. So that isn't safe either. The only path that's good right now is sfc driver removal or the device going away.


No. Adding multi PF support brings new problems. I need to look at the 
other unbinding options I was not contemplating, but acpi module and mem 
unbinding are safe. Maybe not correct semantically, but safe.


>>
>> All this user space potential actions were implemented mainly for testing (I guess you know this). I did ask Dan about it, and I was expecting use cases where HDM decoders and regions are dynamically created, which makes a lot of sense to me, but the fact is all is relying on firmware/BIOS configuration. Richard is working on adding this functionality for Type2 and pmems, and Jonathan considers it theoretically useful as well, but the way is going to be handled requires, IMO, further thinking and maybe a change before someone starts using it (does anyone know about users now?).
>>
>>
>> As a summary, if we allow user space actions (at least for Type2) they need to be consistent and somehow protected.
>>
>>
>> Finally, you did not answer my question: what is the point user space removing and endpoint port handled by a Type2 driver? What about the cxl region? Maybe I am missing a necessity I can not see here, so please, help me to understand this if that is the case.
> Shouldn't does not mean does not exist. Sure I can agree with you that under normal operations, certain things a sane user should avoid doing for type2. But it is possible currently and those issues can be triggered. However you feel about the current CXL architecture, here we are with where it is. You can either consider the smaller changes I suggested to keep the attach->cxlr sane (or with some other means) and make what you need working now with raised the issue addressed, and come back with hashing out the larger grievances later, or keep beating this horse.... "It's silly for users to do that and therefore the issue can be ignored" is not a good enough reason for me look the other way and merge the code.


I'm not denying the problem. I just do not want to add some new 
functionality which comes with these new issues, at least until I can 
understand it fully. What you propose is, I think, correct, and fixing 
at least some of the issues. But I think this is a good opportunity for 
trying to address this sysfs functionality, or at least to discuss it. 
As I said, also when basic Type2 support upstream effort started, Type2 
CXL should not be "open" to user space as Type3 (or not by default), 
although I think this complexity and so many different unwinding paths 
should be avoided ... or documented the reason behind it.


So, I will work on some documentation about all this, with cxl devices 
lifespan and those different unwinding paths, emphasising the different 
theoretical needs between Type2 and Type3. Once the unwinding paths are 
identified and documented, someone  can add the reason/use case behind 
it, or maybe some problems with them we are not seeing now.