Linux CXL
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Yee Li <seven.yi.lee@gmail.com>, <linux-cxl@vger.kernel.org>
Subject: Re: Is there any plan to support CXL GPF in Linux
Date: Mon, 8 Jul 2024 17:42:39 -0700	[thread overview]
Message-ID: <668c877f86daf_102cc2941b@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <CALX8JfQ1F+DJ1woPP=gFvnEyy4qHqGkN+94CKG5ONQy+L3C5_A@mail.gmail.com>

Yee Li wrote:
> Dear All,
> 
> Based on CXL Memory Device SW Guide and CXL Spec, the OS driver plays
> a part in the CXL GPF sequence for persistent memory (like Samsung
> CMM-H).
> 
> So, is there any plan to support CXL GPF in Linux?

See the "Maturity Map" [1] document for what the driver supports.

[1]: http://lore.kernel.org/172005486862.2048248.6668794717827294862.stgit@dwillia2-xfh.jf.intel.com

In terms of "plans", it is in the "patches welcome" state. While CXL
PMEM was an early focus of the kernel enabling, no PMEM devices
materialized in the market so focus moved elsewhere.

> Including init GPF DVSEC, flush data to GPF domain, etc.

One thing that guide does not cover is what should OS software do with a
dirty shutdown failure. To my knowledge there is no specific plumbing
for handling NVME device write-cache failures beyond: "hope filesystem
logging and metadata checksums can recover a consistent filesystem".

I do agree that the driver has a responsibility to set switch timeout
values, but that is more an unfortunate complexity imposed by the spec.
Just set the max and rely on devices to minimize GPF response times to
avoid the worst case wait times that those timeouts imply. In any event,
enabling that is "up for grabs."

  reply	other threads:[~2024-07-09  0:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27  8:28 Is there any plan to support CXL GPF in Linux Yee Li
2024-07-09  0:42 ` Dan Williams [this message]
2024-07-09  6:06   ` Christoph Hellwig
2024-07-09  7:22     ` Yee Li
2024-07-09  7:35       ` Christoph Hellwig
2024-07-09  9:31         ` Yee Li
2024-07-09 19:13           ` Dan Williams
2024-07-10  3:46             ` Yee Li
2024-07-09 18:33     ` Dan Williams

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=668c877f86daf_102cc2941b@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=seven.yi.lee@gmail.com \
    /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