From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Gregory Price <gourry@gourry.net>
Cc: "Cheatham, Benjamin" <benjamin.cheatham@amd.com>,
<linux-cxl@vger.kernel.org>
Subject: Re: RFC: CXL Isolation Support
Date: Mon, 2 Feb 2026 15:59:05 +0000 [thread overview]
Message-ID: <20260202155905.00000cb0@huawei.com> (raw)
In-Reply-To: <aX0jC3DEqcnyrg7x@gourry-fedora-PF4VCD3F>
On Fri, 30 Jan 2026 16:30:51 -0500
Gregory Price <gourry@gourry.net> wrote:
> On Fri, Jan 30, 2026 at 01:47:08PM -0600, Cheatham, Benjamin wrote:
> > Technical Details
> > =================
> >
> > 1. CXL memory may be used for kernel allocations
> >
> > Kernel allocations in CXL aren't a problem at the moment because if the CXL.mem
> > link goes down the hardware resets. When isolation is enabled, this isn't the case.
> > The kernel can keep chugging along until it eventually errors out trying to access
> > the now inaccessible memory (possibly causing data corruption until then).
> >
>
> Two points:
>
> 1) isolating the normal native sysram usecase (N_MEMORY node) buys you
> less reliability than you think. It only buys you kernel safety.
>
> Keeping kernel memory out of CXL only helps the kernel report problems,
> it doesn't necessarily guarantee any particular system state in
> userland after that occurs.
>
> It's entirely possible (and altogether likely) that a large swath of
> userland will become inoperable if the entire link goes down and a bunch
> of that memory was used.
>
> So if the goal is to have the system fully recover, this would require
> much more isolation policy than just keeping the kernel out of CXL - you
> would need most of the baseline distro to set cpuset.mem policies for
> core services that ensure the userspace environment doesn't completely
> blow up.
>
> But even then, you have bigger issues for shared file-backed VMAs.
>
> e.g. imagine libc gets demoted and comes back poisoned: kabloooey
>
> But, you can at least get data from the system that the link went
> down and even have a chance to investigate before nicely blowing up.
>
> Which is at least much more helpful.
Let's pretend it's tagged (just for ease of thinking about it).
So shareable that happens not be shared ever.
Application specific memory isolated to one application - using
famfs or similar.
Then it's safe enough, but maybe not that useful. It's a possible
path to get to a world in which type 3 mem an be isolated.
Jonathan
next prev parent reply other threads:[~2026-02-02 15:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 19:47 RFC: CXL Isolation Support Cheatham, Benjamin
2026-01-30 21:30 ` Gregory Price
2026-02-02 15:59 ` Jonathan Cameron [this message]
2026-02-02 16:50 ` Gregory Price
2026-02-02 17:31 ` Cheatham, Benjamin
2026-02-02 17:30 ` Cheatham, Benjamin
2026-02-02 19:52 ` Gregory Price
2026-02-02 15:52 ` Jonathan Cameron
2026-02-02 19:28 ` Vikram Sethi
2026-02-02 20:20 ` dan.j.williams
2026-02-05 20:49 ` Cheatham, Benjamin
2026-02-05 21:52 ` dan.j.williams
2026-02-05 22:54 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260202155905.00000cb0@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=benjamin.cheatham@amd.com \
--cc=gourry@gourry.net \
--cc=linux-cxl@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox