Re: RFC: CXL Isolation Support

[<dan.j.williams@intel.com>]

Cheatham, Benjamin wrote:
> On 2/2/2026 2:20 PM, dan.j.williams@intel.com wrote:
[..]
> > I am interested in the isolation for CXL accelerator discussion. I am
> > not interested in muddying through isolation for the general memory
> > expander use case without engagement from deployment use cases.
> 
> I can't remember any internal discussions about using isolation for only accelerators so
> I'll need to check and see if that's something we're interested in.
> 
> As for the memory expander case: would something like the N_PRIVATE
> node set Gregory sent out [1] be enough to change your mind on this?
> It doesn't provide the same guarantees as a type 2 set would, but it
> does limit the usage of CXL memory to be more like type 2 memory.

It is not clear to me that can provide the guarantees needed to make
isolation useful. It is still fundamentally a core-mm services
capability. That effort is not well served if it needs to handle the
constraint of: "consider that at any moment this entire node starts
throwing poison, the system needs to stay alive through that event".

> Regardless, I (really) won't bring it up again until we have someone who wants to deploy this thing.

I am always open to reconsidering positions in the face of new evidence.
The workable aspect of a direct-attached-accelerator first approach is
that the accelerator driver has direct ownership of the error model.
Compare that to the core-mm which only considers a page failure model,
not a node failure model. The direct-attached-accelerator constraint is
enough to get some core enabling in the pipeline. Expansions from that
baseline can be evaluated later.