From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19498D11185 for ; Mon, 4 Nov 2024 06:17:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A49216B007B; Mon, 4 Nov 2024 01:17:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F9CC6B0082; Mon, 4 Nov 2024 01:17:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89AB36B0083; Mon, 4 Nov 2024 01:17:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6DC776B007B for ; Mon, 4 Nov 2024 01:17:00 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D89931208F7 for ; Mon, 4 Nov 2024 06:16:59 +0000 (UTC) X-FDA: 82747403802.15.DA7BB31 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf20.hostedemail.com (Postfix) with ESMTP id 2127B1C0011 for ; Mon, 4 Nov 2024 06:16:17 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=gxWmUGjW; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf20.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730700851; a=rsa-sha256; cv=none; b=Ay+BIT080I9bIU4GZncYaXYz4O3tXP1nBcLSbp89u0HDX+MW0prjgJkc7jwpQOQ6E67/Ea QV28Y+YZyOcMWwM9aBG2iIut6ocyOpNqVJpYFzbyJLz0Vde8yqyMK+1tQNaGPm0sdQfZH5 PXaYURrH2YbHhartKEX4raopp45h3lo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=gxWmUGjW; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf20.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730700851; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TToQVmmc3nat3d+fha3HdsqcfrJIbah1c3Z2m4JRYVM=; b=OjlXxD2Y5CIAVCyW2pDjXdfVBGAyRVHAI8aicdm1CW64cHMTMJ+PRKVXXzIUqDUS5bf3hg v3hhD6CTe/nayK2lRjLkCczTyo/6JoQ6QuH7OZ3CoDvYm5umD4rfv1c0z+uQwnWtv+gWpL QyqhPXS55G/+W7DMu7uP8bmprIIyRQs= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 5122E40E0261; Mon, 4 Nov 2024 06:16:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zBz5o0b0UpVc; Mon, 4 Nov 2024 06:16:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1730701006; bh=TToQVmmc3nat3d+fha3HdsqcfrJIbah1c3Z2m4JRYVM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gxWmUGjWfURLHCQKAnNxXbYnEv7N8fZ0JMD/DFaCwgNtVximKzI2QHqUhUjXqd7AH 1XAxVhPBIs4ExVxLbj1fyseA4YpDCdFfJ/sOUqucIt1h7w9qtvag1pj4YTiGj/6qAw SSYsBt+HTYYkURJFfZdPh4IR19Avp1dvnRdHkxV6hFKQ7UYp0eiFkB9R5Ny9slZLWi sW7WodZtvdoAVwF9u8X93ieUw+CbtdeftXGnX12KX5Usi5WH7DW/RsPGpI+BLJn/jM ESJTUh0cNSJiMHLFsr4fEEAs0HRgCLVxt6ejsovAALp3NAFbZkxhGcNNBnwZd3Bj5v d9qudFSOSpLpFE/FoWsxzduSOalAVIhpJNXNAOwymSoPNuiU6t06jBCAwsv17ql8Sv FWBDWaHKtcNhqp/FSmJka/EylDN6789ysHQOBhs3ZHYCX/k4xFnE9JzCdRdamhpV+b kRV01XKDyyDDh8+rfsZAiyrSQeE4n3SNs+RklTOfzx6ME0BljCLfXgGSA6NiMI1R8g FFR1tUBxWKb/+KITgGjTvGo30GK1e0kLoIOzzhdxc8Kdcf3XONBp1BFK5gNMSrFg/Y L18wEXh2Pz75lqVSljq0ckfB1BVjfAZTJ3k8NbWpbqailEFCundYXT2vAIwq9Cqu+A RhuQfczW5xeKL9dWnOvk08OM= Received: from zn.tnic (p5de8e8eb.dip0.t-ipconnect.de [93.232.232.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4ECA540E0220; Mon, 4 Nov 2024 06:16:00 +0000 (UTC) Date: Mon, 4 Nov 2024 07:15:54 +0100 From: Borislav Petkov To: shiju.jose@huawei.com Cc: linux-edac@vger.kernel.org, linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tony.luck@intel.com, rafael@kernel.org, lenb@kernel.org, mchehab@kernel.org, dan.j.williams@intel.com, dave@stgolabs.net, jonathan.cameron@huawei.com, gregkh@linuxfoundation.org, sudeep.holla@arm.com, jassisinghbrar@gmail.com, dave.jiang@intel.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@huawei.com, prime.zeng@hisilicon.com, roberto.sassu@huawei.com, kangkang.shen@futurewei.com, wanghuiqiang@huawei.com, linuxarm@huawei.com Subject: Re: [PATCH v15 11/15] EDAC: Add memory repair control feature Message-ID: <20241104061554.GOZyhmmo9melwI0c6q@fat_crate.local> References: <20241101091735.1465-1-shiju.jose@huawei.com> <20241101091735.1465-12-shiju.jose@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20241101091735.1465-12-shiju.jose@huawei.com> X-Stat-Signature: jz88c4f6tbddw6coc5xo5qe344a6mix6 X-Rspamd-Queue-Id: 2127B1C0011 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1730700977-554243 X-HE-Meta: U2FsdGVkX1+ElMuK7LJNwFV5n2ecAKgUS8CRMWxGdSuBstmh1L3As2kTpOcd5XJe2NfFN2sC5u11uqhTEUIO0XPwQgl6m9gq75gUhnbtMe6XtVNm9d8H9/SEzr9H3nB/o/X2kL9O2kssoVnzFoPVS334xfL0auDk30jUA/59PcexbobZSQpJzY1mJD4vduBkQMpafy54QMLfca4DXu975TGyZpneDaJb7BX0lRCnI+plxd8gn1HBZE1U1qEiJ/NBUNPAwNdqSDCwnlYR7P6ZJWXNObgFhb0IagAJq6huxCM4aEaqltAAgSJ3abi1NX78zkkyQDv3tum9rbv2A1d0HslDdNh2bISvDQpiJGESbZEIyyIVjBYO6GI+8/1WTvA75TZof+lX8KtUk1pK+vMc3jNohp+7zmSC0LTVv3ckeMVrzR2nEcw1C1zU3IS9U5ekzjjpYSbQeuajWzXLRRoUZXAUtdq++KEq9MC4+AkUd+MpLYR3CTUEp5J+MHMjjI6kJ2L6WcjWpk4unO4nxT1SED4XHVeIxrru32f8KY74mp6cS4DyDLrhMd0IU27+ENksgKfZRIS32ks83o2AVGKROYK9Z2hPN5rzPRzxSvoQDWnsChU6FHFHFD9bfhJkO2fUJ3LmjwgqQkluk0n/2MJ+0JLxY/Xm/xMCxNag/MaPc4AlFnjKa6Wr2zLjpIIdcLvCyaRuBTxxm5LLoJGzJmZyllAHWwjNA0+g2bbsNSccKfnu/eY8wokMQGE7wzH0yP5telCkIYyZwR95ugOFLhu1+0rfqfrUK7JlD0sxTxHFha98qq3DDqEfPxMI1Y56cNdEQRsMWsQ7NoEPhTj8SPBAg8d5U4iptBlHi7s9Zvg+MnF5er43kMHJ1KeGii4QKyK0/opBlpCfJ6uBRFUmc4Yg0TzdIpkiDqxnYa4pJPlJsM4HKqg3/q5CDLcQUsV/4WLzKHeC9heP2osDI6stHSD tab65DiV WA3A6J/TwMy3rzz+D9FU17hez3+3EHIKPbZ932dH/eNOfGRXkU32d9zTd3uHXJ70MTRpya/sAfo2GjgWV+QFpOhAMs7gB8r2anZxvFYuXjpDAITNgv2vXA/F/zGyTcL0+/BdcT2M2E5XHivMjZtpyhH26TThoWxoqdy0xM6qftLKLqlhLJQwN9b3yPWNkttq03q6sAC97OH+3y6Q5RbijK813DhJurdGQmTGuzLtNjnTzMs/uBt45dghpq8p/R4mqs8TfCAW1IJBwpkof9es2fhD3+dIDPoqL/1BjsAdQxe4XIONoqvmZK6wUnHwOlHDatmvmINtuFtVZh9I49PIpXB1P8DNt4nH58Aen X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Nov 01, 2024 at 09:17:29AM +0000, shiju.jose@huawei.com wrote: > From: Shiju Jose > > Add generic EDAC memory repair control, eg. PPR(Post Package Repair), > memory sparing etc, control driver in order to control memory repairs > in the system. Supports sPPR(soft PPR), hPPR(hard PPR), soft/hard memory > sparing, memory sparing at cacheline/row/bank/rank granularity etc. > Device with memory repair features registers with EDAC device driver, > which retrieves memory repair descriptor from EDAC memory repair driver and > exposes the sysfs repair control attributes to userspace in > /sys/bus/edac/devices//mem_repairX/. > > The common memory repair control interface abstracts the control of > arbitrary memory repair functionality into a standardized set of functions. > The sysfs memory repair attribute nodes are only available if the client > driver has implemented the corresponding attribute callback function and > provided operations to the EDAC device driver during registration. What is the valid use case for this thing? > Signed-off-by: Shiju Jose > --- > .../ABI/testing/sysfs-edac-memory-repair | 168 ++++++++ > drivers/edac/Makefile | 2 +- > drivers/edac/edac_device.c | 32 ++ > drivers/edac/mem_repair.c | 367 ++++++++++++++++++ > include/linux/edac.h | 87 +++++ > 5 files changed, 655 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-edac-memory-repair > create mode 100755 drivers/edac/mem_repair.c > > diff --git a/Documentation/ABI/testing/sysfs-edac-memory-repair b/Documentation/ABI/testing/sysfs-edac-memory-repair > new file mode 100644 > index 000000000000..393206b8d418 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-edac-memory-repair > @@ -0,0 +1,168 @@ > +What: /sys/bus/edac/devices//mem_repairX > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + The sysfs EDAC bus devices //mem_repairX subdirectory > + pertains to the memory media repair features control, such as > + PPR (Post Package Repair), memory sparing etc, where > + directory corresponds to a device registered with the EDAC > + device driver for the memory repair features. > + Memory sparing is a repair function that replaces a portion > + of memory (spared memory) with a portion of functional memory. a portion of *faulty* memory - this is the most important aspect here. You want to explain why you're doing the replacing in the first place. Memory which is going bad. This first paragraph is a good explanation: https://pubs.lenovo.com/sr850/memory_module_installation_order_sparing the first hit in a web search here. > + Memory sparing has cacheline/row/bank/rank sparing > + granularities. > + The sysfs attributes nodes for a repair feature are only > + present if the parent driver has implemented the corresponding > + attr callback function and provided the necessary operations > + to the EDAC device driver during registration. > + > +What: /sys/bus/edac/devices//mem_repairX/repair_type > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RO) Type of the repair instance. For eg. sPPR, hPPR, cacheline/ WTH is a "repair instance"? Can we pls make this human readable and not some crap spec language? > + row/bank/rank memory sparing etc. > + 0 - Soft PPR(sPPR) > + 1 - Hard PPR(hPPR) Write out those abbreviations. > + 2 - Cacheline memory sparing > + 3 - Row memory sparing > + 4 - Bank memory sparing > + 5 - Rank memory sparing > + All other values are reserved. > + > +What: /sys/bus/edac/devices//mem_repairX/persist_mode_avail > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RO) Persist repair modes supported in the device. > + 0 - Soft PPR(sPPR)/soft memory sparing (temporary repair). > + 1 - Hard PPR(hPPR)/hard memory sparing (permanent repair). Those need a longer, user-friendly explanation. > + All other values are reserved. > + > +What: /sys/bus/edac/devices//mem_repairX/persist_mode > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Current persist repair mode. > + 0 - Soft PPR(sPPR)/soft memory sparing (temporary repair). > + 1 - Hard PPR(hPPR)/hard memory sparing (permanent repair). > + All other values are reserved. You can kill persist_mode_avail by making this persist_mode return the available modes by reading it. > + > +What: /sys/bus/edac/devices//mem_repairX/dpa_support > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RO) True if supports DPA for a repair operation. > + E.g. PPR, memory sparing. DPA? What?! Why is *that* a sysfs file? > + > +What: /sys/bus/edac/devices//mem_repairX/repair_safe_when_in_use > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RO) True if memory media is accessible and data is retained > + during the memory repair operation. Ditto. > + > +What: /sys/bus/edac/devices//mem_repairX/hpa > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) HPA (Host Physical Address) for memory repair. > + > +What: /sys/bus/edac/devices//mem_repairX/dpa > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) DPA (Device Physical Address) for memory repair. Both need more explanation. > + > +What: /sys/bus/edac/devices//mem_repairX/nibble_mask > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Nibble mask for memory repair. What is that? > + > +What: /sys/bus/edac/devices//mem_repairX/bank_group > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Memory bank group for repair. Ditto. > + > +What: /sys/bus/edac/devices//mem_repairX/bank > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Memory bank for memory repair. > + > +What: /sys/bus/edac/devices//mem_repairX/rank > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Memory rank for repair. > + > +What: /sys/bus/edac/devices//mem_repairX/row > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Row for memory repair. > + > +What: /sys/bus/edac/devices//mem_repairX/column > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Column for memory repair. > + > +What: /sys/bus/edac/devices//mem_repairX/channel > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Channel for memory repair. > + > +What: /sys/bus/edac/devices//mem_repairX/sub_channel > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (RW) Sub-channel for memory repair. All those above: need better explanation and need a way of finding out how many of those are in each device so that the user can actually give a sensible value there. > + > +What: /sys/bus/edac/devices//mem_repairX/query > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (WO) Query whether the repair operation is supported for the > + memory attributes set. Return failure if resources are > + not available to perform repair. > + 1 - issue query. > + All other values are reserved. What?! If anything this should be a "status". > + > +What: /sys/bus/edac/devices//mem_repairX/repair > +Date: Jan 2025 > +KernelVersion: 6.13 > +Contact: linux-edac@vger.kernel.org > +Description: > + (WO) Start the memory repair operation for the memory attributes > + set. Return failure if resources are not available to > + perform repair. > + 1 - issue repair operation. > + All other values are reserved. > + In some states of system configuration (e.g. before address > + decoders have been configured), memory devices (e.g. CXL) > + may not have an active mapping in the main host address > + physical address map. As such, the memory to repair must be > + identified by a device specific physical addressing scheme > + using a DPA. The DPA to use will be presented in related > + error records. Yeh, this needs to be part of the interface and not hidden in some obscure doc. The whole repairing control needs to be explained somewhere so that the user can make an informed decision and *actually* use this thing and not break out a sweat when faced with those gazillion sysfs nodes which don't tell her a whole lot. And look into making that interface more user-friendly. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette