Linux CXL
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Ben Cheatham <Benjamin.Cheatham@amd.com>, <rafael@kernel.org>,
	<dan.j.williams@intel.com>, <linux-cxl@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>
Cc: <bhelgaas@google.com>, <benjamin.cheatham@amd.com>,
	<yazen.ghannam@amd.com>
Subject: RE: [PATCH v5 2/3] ACPI, APEI, EINJ: Add CXL 1.1 EINJ error type support
Date: Tue, 26 Sep 2023 14:36:38 -0700	[thread overview]
Message-ID: <65134ee675c1c_bf9129451@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20230925200127.504256-3-Benjamin.Cheatham@amd.com>

Ben Cheatham wrote:
> Add support for CXL EINJ error types for CXL 1.1 hosts added in ACPI
> v6.5. Because these error types target memory-mapped CXL 1.1 compliant
> downstream ports and not physical (normal/persistent) memory, these
> error types are not currently  allowed through the memory range
> validation done by the EINJ driver.
> 
> The MMIO address of a CXL 1.1 downstream port can be found in the
> cxl_rcrb_addr file in the corresponding dport directory under
> /sys/bus/cxl/devices/portX. CXL 1.1 error types follow the same
> procedure as a memory error type, but with param1 set to the
> downstream port MMIO address.
> 
> Example usage:
> $ cd /sys/kernel/debug/apei/einj
> $ cat available_error_type
>     0x00000008      Memory Correctable
>     0x00000010      Memory Uncorrectable non-fatal
>     0x00000020      Memory Uncorrectable fatal
>     0x00000040      PCI Express Correctable
>     0x00000080      PCI Express Uncorrectable non-fatal
>     0x00000100      PCI Express Uncorrectable fatal
>     0x00008000      CXL.mem Protocol Correctable
>     0x00020000      CXL.mem Protocol Uncorrectable fatal
> $ echo 0x8000 > error_type
> $ echo 0xfffffffffffff000 > param2
> $ echo 0x2 > flags
> $ cat /sys/bus/cxl/devices/portX/dportY/cxl_rcrb_addr
> 0xb2f00000
> $ echo 0xb2f00000 > param1
> $ echo 1 > error_inject

I have the same reaction to this as I did before:

http://lore.kernel.org/r/647817212bcf1_e067a2945@dwillia2-xfh.jf.intel.com.notmuch

Why is per-port error injection being driven from this legacy global
interface where userspace needs to take information from sysfs and walk
it over to this other interface? Especially since "rcrb" is an
implementation detail that will be invalidated with CXL VH topologies?

What I would like to see, since this is a new capability with no need to
be beholden to legacy is to disaggregate the interface to be per-port.

For example:

/sys/kernel/debug/cxl/$mem/{inject,clear}_poison is already established
for memory device poison injection. Why not add something like:

/sys/kernel/debug/cxl/$port/einj_{type,inject}

For triggering errors by the CXL subsystem device name, and unburden
userspace from needing to deal in magic numbers.

  parent reply	other threads:[~2023-09-27  4:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25 20:01 [PATCH v5 0/3] CXL, ACPI, APEI, EINJ: Update EINJ for CXL 1.1 error types Ben Cheatham
2023-09-25 20:01 ` [PATCH v5 1/3] CXL, PCIE: Add cxl_rcrb_addr file to dport_dev Ben Cheatham
2023-09-26 10:50   ` Jonathan Cameron
2023-09-26 16:00     ` Ben Cheatham
2023-09-26 20:23   ` Bjorn Helgaas
2023-09-27 15:30     ` Ben Cheatham
2023-09-26 21:15   ` Dan Williams
2023-09-27 15:31     ` Ben Cheatham
2023-09-25 20:01 ` [PATCH v5 2/3] ACPI, APEI, EINJ: Add CXL 1.1 EINJ error type support Ben Cheatham
2023-09-26 11:04   ` Jonathan Cameron
2023-09-26 16:00     ` Ben Cheatham
2023-09-26 20:22   ` Bjorn Helgaas
2023-09-27 15:31     ` Ben Cheatham
2023-09-26 21:36   ` Dan Williams [this message]
2023-09-27 15:32     ` Ben Cheatham
2023-09-25 20:01 ` [PATCH v5 3/3] ACPI, APEI, EINJ: Update EINJ documentation Ben Cheatham
2023-09-26 11:05   ` Jonathan Cameron
2023-09-26 16:00     ` Ben Cheatham
2023-09-26 20:24   ` Bjorn Helgaas
2023-09-27 15:31     ` Ben Cheatham

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=65134ee675c1c_bf9129451@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Benjamin.Cheatham@amd.com \
    --cc=bhelgaas@google.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=yazen.ghannam@amd.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