Re: [PATCH v6 3/9] cxl/region: Skip decoder reset on detach for autodiscovered regions

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

On 3/24/26 19:46, Dan Williams wrote:
> Alison Schofield wrote:


<snip>


> Like I replied to Alejandro it is not a dependency for the type-2 series
> [1]. It *is* a fix for the issue reported by PJ, but it can go in
> independent of the base type-2 work as a standalone capability.
>
> [1]: http://lore.kernel.org/69b8b9181bafd_452b100cb@dwillia2-mobl4.notmuch


I'm afraid I do not understand what you mean here.


<snip>

> Just like the decoder LOCK bit the preservation setting is a decoder
> property, not a region property. Region auto-assembly is then just an
> automatic way to set that decoder policy.
>
> So, no, I would not expect a new region flag for this policy.


Could it be acceptable an accelerator having the option of locking its 
HDM if not already done by the BIOS?


<snip>


> Appreciate you pulling this together. I want to land type-2 with the
> existing expectation that unload is always destructive then circle back


As I said, v22 had that destructive behavior, but v23 kept the HDM 
committed, as that was what you asked for.


Last v24 has only the support for dealing with committed decoders, what 
is the expectation from current BIOS (Intel and AMD) if a Type2 device 
is found at boot time. I got now some BIOS versions which lock the HDM 
decoder for a Type2 device making impossible any destructive action. The 
reason for only supporting this case is to have a chance to be in time 
for 7.1 with the basic (but good enough) support as there are issues 
with the changes to create a region which will need all to agree on how 
to solve them, and unlikely before 7.1 window closes.


> to address this additional detail because it is more than just decoder
> policy that needs to be managed. The type-2 driver may need help finding
> its platform firmware configured address range if a device reset
> destroyed the decoder settings.
>

And again, this problem should be addressed, IMO, as a follow-up.