[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fa5d6bdd08104cf1a09c4960a0f9bc46@huawei.com>
Date: Fri, 15 Nov 2024 12:21:16 +0000
From: Shiju Jose <shiju.jose@...wei.com>
To: Borislav Petkov <bp@...en8.de>
CC: "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "tony.luck@...el.com" <tony.luck@...el.com>,
"rafael@...nel.org" <rafael@...nel.org>, "lenb@...nel.org" <lenb@...nel.org>,
"mchehab@...nel.org" <mchehab@...nel.org>, "dan.j.williams@...el.com"
<dan.j.williams@...el.com>, "dave@...olabs.net" <dave@...olabs.net>,
"Jonathan Cameron" <jonathan.cameron@...wei.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"sudeep.holla@....com" <sudeep.holla@....com>, "jassisinghbrar@...il.com"
<jassisinghbrar@...il.com>, "dave.jiang@...el.com" <dave.jiang@...el.com>,
"alison.schofield@...el.com" <alison.schofield@...el.com>,
"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>, "ira.weiny@...el.com"
<ira.weiny@...el.com>, "david@...hat.com" <david@...hat.com>,
"Vilas.Sridharan@....com" <Vilas.Sridharan@....com>, "leo.duran@....com"
<leo.duran@....com>, "Yazen.Ghannam@....com" <Yazen.Ghannam@....com>,
"rientjes@...gle.com" <rientjes@...gle.com>, "jiaqiyan@...gle.com"
<jiaqiyan@...gle.com>, "Jon.Grimm@....com" <Jon.Grimm@....com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"naoya.horiguchi@....com" <naoya.horiguchi@....com>, "james.morse@....com"
<james.morse@....com>, "jthoughton@...gle.com" <jthoughton@...gle.com>,
"somasundaram.a@....com" <somasundaram.a@....com>, "erdemaktas@...gle.com"
<erdemaktas@...gle.com>, "pgonda@...gle.com" <pgonda@...gle.com>,
"duenwen@...gle.com" <duenwen@...gle.com>, "gthelen@...gle.com"
<gthelen@...gle.com>, "wschwartz@...erecomputing.com"
<wschwartz@...erecomputing.com>, "dferguson@...erecomputing.com"
<dferguson@...erecomputing.com>, "wbs@...amperecomputing.com"
<wbs@...amperecomputing.com>, "nifan.cxl@...il.com" <nifan.cxl@...il.com>,
tanxiaofei <tanxiaofei@...wei.com>, "Zengtao (B)" <prime.zeng@...ilicon.com>,
"Roberto Sassu" <roberto.sassu@...wei.com>, "kangkang.shen@...urewei.com"
<kangkang.shen@...urewei.com>, wanghuiqiang <wanghuiqiang@...wei.com>,
Linuxarm <linuxarm@...wei.com>
Subject: RE: [PATCH v15 11/15] EDAC: Add memory repair control feature
Hi Boris,
Please find reply inline.
>-----Original Message-----
>From: Borislav Petkov <bp@...en8.de>
>Sent: 14 November 2024 13:33
>To: Shiju Jose <shiju.jose@...wei.com>
>Cc: linux-edac@...r.kernel.org; linux-cxl@...r.kernel.org; linux-
>acpi@...r.kernel.org; linux-mm@...ck.org; linux-kernel@...r.kernel.org;
>tony.luck@...el.com; rafael@...nel.org; lenb@...nel.org;
>mchehab@...nel.org; dan.j.williams@...el.com; dave@...olabs.net; Jonathan
>Cameron <jonathan.cameron@...wei.com>; gregkh@...uxfoundation.org;
>sudeep.holla@....com; jassisinghbrar@...il.com; dave.jiang@...el.com;
>alison.schofield@...el.com; vishal.l.verma@...el.com; ira.weiny@...el.com;
>david@...hat.com; Vilas.Sridharan@....com; leo.duran@....com;
>Yazen.Ghannam@....com; rientjes@...gle.com; jiaqiyan@...gle.com;
>Jon.Grimm@....com; dave.hansen@...ux.intel.com;
>naoya.horiguchi@....com; james.morse@....com; jthoughton@...gle.com;
>somasundaram.a@....com; erdemaktas@...gle.com; pgonda@...gle.com;
>duenwen@...gle.com; gthelen@...gle.com;
>wschwartz@...erecomputing.com; dferguson@...erecomputing.com;
>wbs@...amperecomputing.com; nifan.cxl@...il.com; tanxiaofei
><tanxiaofei@...wei.com>; Zengtao (B) <prime.zeng@...ilicon.com>; Roberto
>Sassu <roberto.sassu@...wei.com>; kangkang.shen@...urewei.com;
>wanghuiqiang <wanghuiqiang@...wei.com>; Linuxarm
><linuxarm@...wei.com>
>Subject: Re: [PATCH v15 11/15] EDAC: Add memory repair control feature
>
>On Mon, Nov 11, 2024 at 04:54:48PM +0000, Shiju Jose wrote:
>> Presently, 0 (soft memory repair) and 1 (hard memory repair), depends
>> on which mode/s a memory device is supported.
>
>What if the device supports more than one mode?
>
>> However for CXL memory sparing feature, the persistent mode is
>> configurable at runtime for a memory sparing instance, thus both soft and
>hard sparing are supported.
>> Example given for CXL memory sparing feature in
>> Documentation/edac/memory_repair.rst,
>> root@...alhost:~# cat
>> /sys/bus/edac/devices/cxl_mem0/mem_repair1/persist_mode_avail
>> 0,1
>
>Ok, and how is the user supposed to know what those mean?
Print in string format?, may be as 'persist'/'volatile'?
>
>> Kernel sysfs doc mentioned about array of values as follows, though not seen
>much examples.
>> https://docs.kernel.org/filesystems/sysfs.html
>> "Attributes should be ASCII text files, preferably with only one value
>> per file. It is noted that it may not be efficient to contain only one
>> value per file, so it is socially acceptable to express an array of values of the
>same type."
>
>True story. Ok, so there's an exception to that rule.
>
>> The values of these attributes are specific to device and portion of the memory
>to repair.
>> For example, In CXL repair features,
>> CXL memory device identifies a failure on a memory component, device
>> provides the corresponding values of the attributes (DPA, channel,
>> rank, nibble mask, bank group, bank, row, column or sub-channel etc) in an
>event record to the host and to the userspace in the corresponding trace event.
>> Userspace shall use these values for the query resource availability and repair
>operations.
>
>I don't think you're answering my question. Lemme try again:
>
>I am on a machine with such an interface. I do
>
>echo 0xdeadbeef > /sys/devices...
>-EINVAL
>
>echo 0xface > ...
>-EINVAL
>
>How do I know what the allowed ranges are?
I am fine with adding the support for expose the ranges of these,
but makes more sense to do it when a driver surfaces that can do it.
I will use the DPA for CXL features as an example of how it would be done and
it's the one is supported now.
>> This will work for the CXL PPR feature where the result of the query
[...]
>--
>Regards/Gruss,
> Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette
Thanks,
Shiju
Powered by blists - more mailing lists