From: Dave Jiang <dave.jiang@intel.com>
To: Shiju Jose <shiju.jose@huawei.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "bp@alien8.de" <bp@alien8.de>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"rafael@kernel.org" <rafael@kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"dave@stgolabs.net" <dave@stgolabs.net>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
"jassisinghbrar@gmail.com" <jassisinghbrar@gmail.com>,
"alison.schofield@intel.com" <alison.schofield@intel.com>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
"ira.weiny@intel.com" <ira.weiny@intel.com>,
"david@redhat.com" <david@redhat.com>,
"Vilas.Sridharan@amd.com" <Vilas.Sridharan@amd.com>,
"leo.duran@amd.com" <leo.duran@amd.com>,
"Yazen.Ghannam@amd.com" <Yazen.Ghannam@amd.com>,
"rientjes@google.com" <rientjes@google.com>,
"jiaqiyan@google.com" <jiaqiyan@google.com>,
"Jon.Grimm@amd.com" <Jon.Grimm@amd.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"jthoughton@google.com" <jthoughton@google.com>,
"somasundaram.a@hpe.com" <somasundaram.a@hpe.com>,
"erdemaktas@google.com" <erdemaktas@google.com>,
"pgonda@google.com" <pgonda@google.com>,
"duenwen@google.com" <duenwen@google.com>,
"gthelen@google.com" <gthelen@google.com>,
"wschwartz@amperecomputing.com" <wschwartz@amperecomputing.com>,
"dferguson@amperecomputing.com" <dferguson@amperecomputing.com>,
"wbs@os.amperecomputing.com" <wbs@os.amperecomputing.com>,
"nifan.cxl@gmail.com" <nifan.cxl@gmail.com>,
tanxiaofei <tanxiaofei@huawei.com>,
"Zengtao (B)" <prime.zeng@hisilicon.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
"kangkang.shen@futurewei.com" <kangkang.shen@futurewei.com>,
wanghuiqiang <wanghuiqiang@huawei.com>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH v14 07/14] cxl/memfeature: Add CXL memory device patrol scrub control feature
Date: Tue, 29 Oct 2024 11:32:47 -0700 [thread overview]
Message-ID: <67b569b0-1cd5-44e0-8465-064b41a1afd8@intel.com> (raw)
In-Reply-To: <e6aed765394b4822ad5a70018c87ef1f@huawei.com>
On 10/29/24 10:00 AM, Shiju Jose wrote:
>
>
>> -----Original Message-----
>> From: Dave Jiang <dave.jiang@intel.com>
>> Sent: 29 October 2024 16:32
>> To: Shiju Jose <shiju.jose@huawei.com>; linux-edac@vger.kernel.org; linux-
>> cxl@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux-
>> kernel@vger.kernel.org
>> Cc: bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org;
>> mchehab@kernel.org; dan.j.williams@intel.com; dave@stgolabs.net; Jonathan
>> Cameron <jonathan.cameron@huawei.com>; gregkh@linuxfoundation.org;
>> sudeep.holla@arm.com; jassisinghbrar@gmail.com; alison.schofield@intel.com;
>> vishal.l.verma@intel.com; ira.weiny@intel.com; david@redhat.com;
>> Vilas.Sridharan@amd.com; leo.duran@amd.com; Yazen.Ghannam@amd.com;
>> rientjes@google.com; jiaqiyan@google.com; Jon.Grimm@amd.com;
>> dave.hansen@linux.intel.com; naoya.horiguchi@nec.com;
>> james.morse@arm.com; jthoughton@google.com; somasundaram.a@hpe.com;
>> erdemaktas@google.com; pgonda@google.com; duenwen@google.com;
>> gthelen@google.com; wschwartz@amperecomputing.com;
>> dferguson@amperecomputing.com; wbs@os.amperecomputing.com;
>> nifan.cxl@gmail.com; tanxiaofei <tanxiaofei@huawei.com>; Zengtao (B)
>> <prime.zeng@hisilicon.com>; Roberto Sassu <roberto.sassu@huawei.com>;
>> kangkang.shen@futurewei.com; wanghuiqiang <wanghuiqiang@huawei.com>;
>> Linuxarm <linuxarm@huawei.com>
>> Subject: Re: [PATCH v14 07/14] cxl/memfeature: Add CXL memory device patrol
>> scrub control feature
>>
>>
>>
>> On 10/25/24 10:13 AM, shiju.jose@huawei.com wrote:
>>> From: Shiju Jose <shiju.jose@huawei.com>
>>>
>>> CXL spec 3.1 section 8.2.9.9.11.1 describes the device patrol scrub
>>> control feature. The device patrol scrub proactively locates and makes
>>> corrections to errors in regular cycle.
>>>
>>> Allow specifying the number of hours within which the patrol scrub
>>> must be completed, subject to minimum and maximum limits reported by the
>> device.
>>> Also allow disabling scrub allowing trade-off error rates against
>>> performance.
>>>
>>> Add support for patrol scrub control on CXL memory devices.
>>> Register with the EDAC device driver, which retrieves the scrub
>>> attribute descriptors from EDAC scrub and exposes the sysfs scrub
>>> control attributes to userspace. For example, scrub control for the
>>> CXL memory device "cxl_mem0" is exposed in
>> /sys/bus/edac/devices/cxl_mem0/scrubX/.
>>>
>>> Additionally, add support for region-based CXL memory patrol scrub control.
>>> CXL memory regions may be interleaved across one or more CXL memory
>>> devices. For example, region-based scrub control for "cxl_region1" is
>>> exposed in /sys/bus/edac/devices/cxl_region1/scrubX/.
>>>
>>> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
>>> ---
>>> Documentation/edac/edac-scrub.rst | 74 ++++++
>>> drivers/cxl/Kconfig | 18 ++
>>> drivers/cxl/core/Makefile | 1 +
>>> drivers/cxl/core/memfeature.c | 381 ++++++++++++++++++++++++++++++
>>> drivers/cxl/core/region.c | 6 +
>>> drivers/cxl/cxlmem.h | 7 +
>>> drivers/cxl/mem.c | 4 +
>>> 7 files changed, 491 insertions(+)
>>> create mode 100644 Documentation/edac/edac-scrub.rst create mode
>>> 100644 drivers/cxl/core/memfeature.c
>>>
>>> diff --git a/Documentation/edac/edac-scrub.rst
>>> b/Documentation/edac/edac-scrub.rst
>>> new file mode 100644
>>> index 000000000000..4aad4974b208
>>> --- /dev/null
>>> +++ b/Documentation/edac/edac-scrub.rst
>>> @@ -0,0 +1,74 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
> [...]
>
>>> +static int cxl_mem_ps_get_attrs(struct cxl_memdev_state *mds,
>>> + struct cxl_memdev_ps_params *params) {
>>> + size_t rd_data_size = sizeof(struct cxl_memdev_ps_rd_attrs);
>>> + size_t data_size;
>>> + struct cxl_memdev_ps_rd_attrs *rd_attrs __free(kfree) =
>>> + kmalloc(rd_data_size,
>> GFP_KERNEL);
>>> + if (!rd_attrs)
>>> + return -ENOMEM;
>>> +
>>> + data_size = cxl_get_feature(mds, cxl_patrol_scrub_uuid,
>>> + CXL_GET_FEAT_SEL_CURRENT_VALUE,
>>> + rd_attrs, rd_data_size);
>>> + if (!data_size)
>>> + return -EIO;
>>> +
>>> + params->scrub_cycle_changeable =
>> FIELD_GET(CXL_MEMDEV_PS_SCRUB_CYCLE_CHANGE_CAP_MASK,
>>> + rd_attrs->scrub_cycle_cap);
>>> + params->enable =
>> FIELD_GET(CXL_MEMDEV_PS_FLAG_ENABLED_MASK,
>>> + rd_attrs->scrub_flags);
>>> + params->scrub_cycle_hrs =
>> FIELD_GET(CXL_MEMDEV_PS_CUR_SCRUB_CYCLE_MASK,
>>> + rd_attrs->scrub_cycle_hrs);
>>> + params->min_scrub_cycle_hrs =
>> FIELD_GET(CXL_MEMDEV_PS_MIN_SCRUB_CYCLE_MASK,
>>> + rd_attrs->scrub_cycle_hrs);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int cxl_ps_get_attrs(struct device *dev, void *drv_data,
>>
>> Would a union be better than a void *drv_data for all the places this is used as a
>> parameter? How many variations of this are there?
>>
>> DJ
> Hi Dave,
>
> Can you give more info on this given this is a generic callback for the scrub control and each
> implementation will have its own context struct (for eg. struct cxl_patrol_scrub_context here
> for CXL scrub control), which in turn will be passed in and out as opaque data.
Mainly I'm just seeing a lot of calls with (void *). Just asking if we want to make it a union that contains 'struct cxl_patrol_scrub_context' and etc.
>
> Thanks,
> Shiju
>>
>>> + struct cxl_memdev_ps_params *params) {
>>> + struct cxl_patrol_scrub_context *cxl_ps_ctx = drv_data;
>>> + struct cxl_memdev *cxlmd;
>>> + struct cxl_dev_state *cxlds;
>>> + struct cxl_memdev_state *mds;
>>> + u16 min_scrub_cycle = 0;
>>> + int i, ret;
>>> +
>>> + if (cxl_ps_ctx->cxlr) {
>>> + struct cxl_region *cxlr = cxl_ps_ctx->cxlr;
>>> + struct cxl_region_params *p = &cxlr->params;
>>> +
>>> + for (i = p->interleave_ways - 1; i >= 0; i--) {
>>> + struct cxl_endpoint_decoder *cxled = p->targets[i];
>>> +
>>> + cxlmd = cxled_to_memdev(cxled);
>>> + cxlds = cxlmd->cxlds;
>>> + mds = to_cxl_memdev_state(cxlds);
>>> + ret = cxl_mem_ps_get_attrs(mds, params);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (params->min_scrub_cycle_hrs > min_scrub_cycle)
>>> + min_scrub_cycle = params-
>>> min_scrub_cycle_hrs;
>>> + }
>>> + params->min_scrub_cycle_hrs = min_scrub_cycle;
>>> + return 0;
>>> + }
>>> + cxlmd = cxl_ps_ctx->cxlmd;
>>> + cxlds = cxlmd->cxlds;
>>> + mds = to_cxl_memdev_state(cxlds);
>>> +
>>> + return cxl_mem_ps_get_attrs(mds, params); }
>>> +
> [...]
>>
>
next prev parent reply other threads:[~2024-10-29 18:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 17:13 [PATCH v14 00/14] EDAC: Scrub: introduce generic EDAC RAS control feature driver + CXL/ACPI-RAS2 drivers shiju.jose
2024-10-25 17:13 ` [PATCH v14 01/14] EDAC: Add support for EDAC device features control shiju.jose
2024-10-25 17:13 ` [PATCH v14 02/14] EDAC: Add scrub control feature shiju.jose
2024-10-25 17:13 ` [PATCH v14 03/14] EDAC: Add ECS " shiju.jose
2024-10-28 11:16 ` Borislav Petkov
2024-10-28 16:03 ` Shiju Jose
2024-10-29 20:07 ` Borislav Petkov
2024-10-25 17:13 ` [PATCH v14 04/14] cxl: Add Get Supported Features command for kernel usage shiju.jose
2024-10-25 17:13 ` [PATCH v14 05/14] cxl/mbox: Add GET_FEATURE mailbox command shiju.jose
2024-10-29 15:47 ` Dave Jiang
2024-10-25 17:13 ` [PATCH v14 06/14] cxl/mbox: Add SET_FEATURE " shiju.jose
2024-10-29 15:51 ` Dave Jiang
2024-10-25 17:13 ` [PATCH v14 07/14] cxl/memfeature: Add CXL memory device patrol scrub control feature shiju.jose
2024-10-29 16:31 ` Dave Jiang
2024-10-29 17:00 ` Shiju Jose
2024-10-29 18:32 ` Dave Jiang [this message]
2024-10-30 16:16 ` Jonathan Cameron
2024-10-30 16:46 ` Dave Jiang
2024-10-29 20:15 ` Borislav Petkov
2024-10-30 12:52 ` Shiju Jose
2024-10-29 20:16 ` Borislav Petkov
2024-10-30 11:26 ` Shiju Jose
2024-10-25 17:13 ` [PATCH v14 08/14] cxl/memfeature: Add CXL memory device ECS " shiju.jose
2024-10-25 17:13 ` [PATCH v14 09/14] ACPI:RAS2: Add ACPI RAS2 driver shiju.jose
2024-10-25 17:13 ` [PATCH v14 10/14] ras: mem: Add memory " shiju.jose
2024-10-25 17:13 ` [PATCH v14 11/14] EDAC: Add memory repair control feature shiju.jose
2024-10-25 17:13 ` [PATCH v14 12/14] cxl/mbox: Add support for PERFORM_MAINTENANCE mailbox command shiju.jose
2024-10-25 17:13 ` [PATCH v14 13/14] cxl/memfeature: Add CXL memory device sPPR control feature shiju.jose
2024-10-25 17:13 ` [PATCH v14 14/14] cxl/memfeature: Add CXL memory device memory sparing " shiju.jose
2024-10-26 10:35 ` [PATCH v14 00/14] EDAC: Scrub: introduce generic EDAC RAS control feature driver + CXL/ACPI-RAS2 drivers Borislav Petkov
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=67b569b0-1cd5-44e0-8465-064b41a1afd8@intel.com \
--to=dave.jiang@intel.com \
--cc=Jon.Grimm@amd.com \
--cc=Vilas.Sridharan@amd.com \
--cc=Yazen.Ghannam@amd.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dferguson@amperecomputing.com \
--cc=duenwen@google.com \
--cc=erdemaktas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=gthelen@google.com \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=jassisinghbrar@gmail.com \
--cc=jiaqiyan@google.com \
--cc=jonathan.cameron@huawei.com \
--cc=jthoughton@google.com \
--cc=kangkang.shen@futurewei.com \
--cc=lenb@kernel.org \
--cc=leo.duran@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=mchehab@kernel.org \
--cc=naoya.horiguchi@nec.com \
--cc=nifan.cxl@gmail.com \
--cc=pgonda@google.com \
--cc=prime.zeng@hisilicon.com \
--cc=rafael@kernel.org \
--cc=rientjes@google.com \
--cc=roberto.sassu@huawei.com \
--cc=shiju.jose@huawei.com \
--cc=somasundaram.a@hpe.com \
--cc=sudeep.holla@arm.com \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.com \
--cc=vishal.l.verma@intel.com \
--cc=wanghuiqiang@huawei.com \
--cc=wbs@os.amperecomputing.com \
--cc=wschwartz@amperecomputing.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