From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: <alison.schofield@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Ben Widawsky <bwidawsk@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>, <linux-cxl@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/6] cxl/memdev: Add trigger_poison_list sysfs attribute
Date: Wed, 16 Nov 2022 12:48:55 +0000 [thread overview]
Message-ID: <20221116124855.00002f58@Huawei.com> (raw)
In-Reply-To: <5055dd47526d900f85f43bb0d85f4ccd4c9502b6.1668115235.git.alison.schofield@intel.com>
On Thu, 10 Nov 2022 19:12:41 -0800
alison.schofield@intel.com wrote:
> From: Alison Schofield <alison.schofield@intel.com>
>
> When a boolean 'true' is written to this attribute the memdev driver
> retrieves the poison list from the device. The list includes addresses
> that are poisoned, or would result in poison if accessed, and the
> source of the poison. This attribute is only visible for devices
> supporting the capability. The retrieved errors are logged as kernel
> trace events with the label 'cxl_poison'.
>
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Hi Alison,
A few comments inline.
Jonathan
> ---
> Documentation/ABI/testing/sysfs-bus-cxl | 14 +++++++++
> drivers/cxl/core/memdev.c | 41 +++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
> index 8494ef27e8d2..1c5f4a853ba2 100644
> --- a/Documentation/ABI/testing/sysfs-bus-cxl
> +++ b/Documentation/ABI/testing/sysfs-bus-cxl
> @@ -388,3 +388,17 @@ Description:
> 1), and checks that the hardware accepts the commit request.
> Reading this value indicates whether the region is committed or
> not.
> +
> +
> +What: /sys/bus/cxl/devices/memX/trigger_poison_list
> +Date: November, 2022
> +KernelVersion: v6.2
> +Contact: linux-cxl@vger.kernel.org
> +Description:
> + (WO) When a boolean 'true' is written to this attribute the
> + memdev driver retrieves the poison list from the device. The
> + list includes addresses that are poisoned or would result in
> + poison if accessed, and the source of the poison. This
Trivial, but 'includes' kind of implies it might have other things as well.
The list consists of addresses that are... perhaps?
> + attribute is only visible for devices supporting the
> + capability. The retrieved errors are logged as kernel
> + trace events with the label 'cxl_poison'.
> diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> index 20ce488a7754..06d265db5127 100644
> --- a/drivers/cxl/core/memdev.c
> +++ b/drivers/cxl/core/memdev.c
> @@ -106,12 +106,45 @@ static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
> }
> static DEVICE_ATTR_RO(numa_node);
>
> +static ssize_t trigger_poison_list_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> + struct cxl_dev_state *cxlds = cxlmd->cxlds;
> + u64 offset, length;
> + bool tmp;
> + int rc;
> +
> + if (kstrtobool(buf, &tmp))
> + return -EINVAL;
> +
> + /* Per CXL Spec, separate the pmem and ram poison list reads */
Reference? I assume this is the bit about what happens if the
device doesn't support poison list retrieval for volatile memory?
I can't find anything more specific but maybe I'm looking in wrong place.
> + if (resource_size(&cxlds->pmem_res)) {
> + offset = cxlds->pmem_res.start;
> + length = resource_size(&cxlds->pmem_res);
> + rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
> + if (rc)
> + return rc;
> + }
> + if (resource_size(&cxlds->ram_res)) {
> + offset = cxlds->ram_res.start;
> + length = resource_size(&cxlds->ram_res);
> + rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
> + if (rc)
> + return rc;
Hmm. So should we handle the return of Invalid Physical Address as an
error or not? I think not given it's optional to support the poison
list for volatile memory.
> + }
> + return len;
> +}
> +static DEVICE_ATTR_WO(trigger_poison_list);
> +
> static struct attribute *cxl_memdev_attributes[] = {
> &dev_attr_serial.attr,
> &dev_attr_firmware_version.attr,
> &dev_attr_payload_max.attr,
> &dev_attr_label_storage_size.attr,
> &dev_attr_numa_node.attr,
> + &dev_attr_trigger_poison_list.attr,
> NULL,
> };
>
> @@ -130,6 +163,14 @@ static umode_t cxl_memdev_visible(struct kobject *kobj, struct attribute *a,
> {
> if (!IS_ENABLED(CONFIG_NUMA) && a == &dev_attr_numa_node.attr)
> return 0;
> +
> + if (a == &dev_attr_trigger_poison_list.attr) {
> + struct device *dev = kobj_to_dev(kobj);
> +
> + if (!test_bit(CXL_MEM_COMMAND_ID_GET_POISON,
> + to_cxl_memdev(dev)->cxlds->enabled_cmds))
> + return 0;
> + }
> return a->mode;
> }
>
next prev parent reply other threads:[~2022-11-16 12:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 3:12 [PATCH v3 0/6] CXL Poison List Retrieval & Tracing alison.schofield
2022-11-11 3:12 ` [PATCH v3 1/6] trace, cxl: Introduce a TRACE_EVENT for CXL poison records alison.schofield
2022-11-16 12:19 ` Jonathan Cameron
2022-12-04 22:42 ` Dan Williams
2022-11-11 3:12 ` [PATCH v3 2/6] cxl/mbox: Add GET_POISON_LIST mailbox command alison.schofield
2022-11-16 12:41 ` Jonathan Cameron
2022-11-17 23:55 ` Alison Schofield
2022-12-07 2:41 ` Dan Williams
2022-12-07 16:10 ` Alison Schofield
2022-12-07 21:39 ` Dan Williams
2022-12-08 3:47 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 3/6] cxl/memdev: Add trigger_poison_list sysfs attribute alison.schofield
2022-11-16 12:48 ` Jonathan Cameron [this message]
2022-11-18 0:15 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 4/6] cxl/region: " alison.schofield
2022-11-16 12:50 ` Jonathan Cameron
2022-11-18 0:24 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 5/6] tools/testing/cxl: Mock the max err records field of Identify cmd alison.schofield
2022-11-16 12:51 ` Jonathan Cameron
2022-11-18 0:25 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 6/6] tools/testing/cxl: Mock the Get Poison List mbox command alison.schofield
2022-11-16 12:52 ` Jonathan Cameron
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=20221116124855.00002f58@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vishal.l.verma@intel.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