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 701F0E77188 for ; Tue, 14 Jan 2025 14:26:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB60F6B007B; Tue, 14 Jan 2025 09:26:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D3F196B0083; Tue, 14 Jan 2025 09:26:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B91B06B0085; Tue, 14 Jan 2025 09:26:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 993766B007B for ; Tue, 14 Jan 2025 09:26:32 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2AFC31A0A9E for ; Tue, 14 Jan 2025 14:26:32 +0000 (UTC) X-FDA: 83006283024.06.FC2681C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 645F94000A for ; Tue, 14 Jan 2025 14:26:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rVoqCHDR; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of mchehab+huawei@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736864790; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=acPd3NC418UDJ6QbfRfBpZ1DndUH88+NxYUxCp8ED9M=; b=ZxwjsMhL1L6UOyH/Iioiu3d5ZMEev5rZ5uaP+KpzICEXj89ruZD0Vyb9GqU8MjjoVrOtSU rRSXn1RHjtuqX1qAkb2u4pH2sKYEQHw29/RiLnncNcWR7AolyJTFnKFjGSiq1IZY6J7TC/ //T0D6cfCCeRPol326caucguxIBw0l4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736864790; a=rsa-sha256; cv=none; b=aDOyz/ONFuR2t4XRtkHsfbI8ASuBNKnfX07BWR8oKEHnbsU+wbeVDFU+sAqmRY/mNxjYwT JPVM6YxUvgJly7Nef+bLXKG4d0amLltoy+m8qoBNxqKQWCuDv42LoUdHuAvyeas6C4VmrZ sV1xSOaQOwjaBmNGMCTLNUA5faG4RPc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rVoqCHDR; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of mchehab+huawei@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 661B65C02ED; Tue, 14 Jan 2025 14:25:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B9C6C4CEDD; Tue, 14 Jan 2025 14:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736864788; bh=6lPeIc8Kx8uL1jk1fEfVYaiiW/b6yM7rLPWmuu7ZTrQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rVoqCHDR2OS2gurGtQV8Sny/VzC3eahz+N7IHkK416GzX8lOUSndcfHuw1aqLUK0p iQ2sFrtsSlDOeREcQcWfQQtN1mxIDzhKjMbN/ANsAaAlv4Z0ESwfuxNXxLpDSlMmmm Gy47zbS5mEIPOABkeU91/4szqfTHMoio1PBtKYsWQD/A+kmo2yjIu0gkDiMX22pCuk 4HDe6PWExShJUqy5PkLL1S0Gw4v3j7X0ZQXcLJDbqMtjnNiBmFiwIBP24m1PmVATi1 eB4KKqVDwFijXh0FsU7uxqS3XQdKY7D1hZCreG5XZBiJYRrNcgavEy+bJjuvdnCCp9 l+hMv9MzfQuyw== Date: Tue, 14 Jan 2025 15:26:17 +0100 From: Mauro Carvalho Chehab To: Shiju Jose 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" , "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" , "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 , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature Message-ID: <20250114152617.14eb41b5@foz.lan> In-Reply-To: References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250114124740.2b311cd1@foz.lan> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: tdomwqcj4um9i7bhmr5bdrcsawctoxc1 X-Rspamd-Queue-Id: 645F94000A X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736864790-240302 X-HE-Meta: U2FsdGVkX1/h3gR1VnnJxZd/N+c8IKPqFdUPl5xAwHyewFJtgH6V98YPWECAIH/bly7A/zETD4+SIrTmIb6L5MTMXLl8XzMraAHb+ENBYxx3QFPgCWhNOcDO1KeeHbvUP2liso0t5W0QlOu7MErVed9YUHmVI8TPlDwLyVncTV3N8tXYyNxiLKvAnU1Xpk4ARshE/O5vDX0OUCSJQMLwLV/pRA2CD1eu7lvfOG5rcQPcI10O04A8zdfCcMTf4gcA4ZYyfMjwG1yO0FTpGzsV+brV6b/DVxc6qA8T+UK9Z97lbO4rp89giit+o1Qlom8tH7Xd5Tw40hBZPuvQf0e6UBlkfHkzNMJ9K4wB507vLvLgmfGdNCkU6NqZipHSo7Lori+9c5n9dJyt4AWM/u4FN6BH5m11RsvKw4W6B2mspBW3Dgl0o/f6JS2cQK3eVufcZ+0Bg6GIpZ6ZvLioksBk/lbg2YfGnnIDIswhT2s+yelQ4y6eTOlLhj0J+CPpWc9+PKBWrxwEDXVrl8E4lxV9+x4W3LCORGIF2bUeJYhSEChYvoBEwtJmDu8aa+67w6w5Y9KBKX45OxEpV+k3IdtIpnvJvAj8BYmRcE/YPOMvW+/qDND9tSpQQsfvIzKn1IrKVToi9sobzdcWdilpHMPU29kmhqiPz+NBrBPo31BWkDR5SiRc06/2xwF0bPQXOy5I5dOi+ql+fxpbl1kpisiHa5pMdN7gVuF4yduxDoPrM3nHbUAOLT+ci0vlc+fXGZAJZSEYHYDhkQtVqYUJgHAXiiYS+qMXx7+TlZ+iEfqwpD1pob08fX4YI7bf724RxqNiEr6d/Jw3kK55R4ZohgyYHDxSQDr2pY6Bj4bmGh5AQDUbI+KODT5tOCJyvTgz28uluim0sDaY9DO/Hqpzq+Luvx7AACBi6pvUKkBv/YgK2NFvYlJvuQoQ3UpHMBk37T7HczIxx0VroHZHa2Kpgge nC+Exeqj AXuejMqS1OkKhc+ghkE6PaX1Cw7VE6pAV4r3UhsgPq/ztHj46Dyiuql7P4lrN+bVeuWfdFMK/eNbsHaHyBJarmOpFwjOZzgozD1i/T3ebj4eJWiyjgUT6LZvWKJ6yNZTtOZoStZWmmYfAlSoBskujFWSBPkfRCRw/T+tDvcxCn6ZyCY5STgbb9OpIf3EdrdW3vM0iePh1zbKMWqOmEFaIybyVc5DtXEfyv4JHJc5be1Kxgvvo6onIPXTHXeaizwg+QVa4WvQy3L1MBfZnyK3IaKPLSh9D9WImighcytl1RiFkeRgIzVzfT4QszeQA73Sgk5K0Q5qFf5HVzLDVuhkrSMXHOBOq4wITwRoEL94LytsGUVDbhwoj1RsDpPmsOEumylnYTCn2rnPVlwzfhVFX1JGPizn8Ok/7jIt7OsDuE02kYEyQwyOaXw03T5ZkeJ3Mjs+hJDxTAMmP38mLjlG/SakOdXC88O2ezOsgnZjcNucQv9lzB0AsO6nL1k0+Xj1bu8UIOYnWC80hkHEVxWo3uD0jf9f4wSnglxX6px5uW6ZttxX56F6/2FIMybgAiagGiNiWlXBQJvAISeZOJ+mmwnd1BZcLj8Fb4NepqvCyBFReoeLIg8ZvYLpPWKGOi2spONoe+6UK+ADwNHfxvMP3G0ioo88vvrsw0OMQme7JcaazkRpd0dc8QowVQRLY56hIaSkUCR5yJJVVNbQaDWSvsL8/l6SYl6pc6TVX+gXFrdNDOU/SoEDtLG4G9v4mlRywCjY2/8nS9QF8VUCJpkeou9nLjZ1rI2bZLl8HMi4EVJjcE9O31Y4oF8LhvaO5ji24IYDU6Msh/Lx79nqgu9S0MV8Lepw5ihN2qX0cO7De1wwl6QHaVIqBPpC6fW5KbCQfpUw/ah7Q25iApWg= 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: Em Tue, 14 Jan 2025 12:31:44 +0000 Shiju Jose escreveu: > Hi Mauro, > > Thanks for the comments. > > >-----Original Message----- > >From: Mauro Carvalho Chehab > >Sent: 14 January 2025 11:48 > >To: Shiju Jose > >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; > >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 ; 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 > >; Zengtao (B) ; Roberto > >Sassu ; kangkang.shen@futurewei.com; > >wanghuiqiang ; Linuxarm > > > >Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature > > > >Em Mon, 6 Jan 2025 12:10:00 +0000 > > escreveu: > > > >> From: Shiju Jose > >> > >> Add a generic EDAC memory repair control driver to manage memory repairs > >> in the system, such as CXL Post Package Repair (PPR) and CXL memory sparing > >> features. > >> > >> For example, a CXL device with DRAM components that support PPR features > >> may implement PPR maintenance operations. DRAM components may support > >two > >> types of PPR, hard PPR, for a permanent row repair, and soft PPR, for a > >> temporary row repair. Soft PPR is much faster than hard PPR, but the repair > >> is lost with a power cycle. > >> Similarly a CXL memory device may support soft and hard memory sparing at > >> cacheline, row, bank and rank granularities. Memory sparing is defined as > >> a repair function that replaces a portion of memory with a portion of > >> functional memory at that same granularity. > >> When a CXL device detects an error in a memory, it may report the host of > >> the need for a repair maintenance operation by using an event record where > >> the "maintenance needed" flag is set. The event records contains the device > >> physical address(DPA) and other attributes of the memory to repair (such as > >> channel, sub-channel, bank group, bank, rank, row, column etc). The kernel > >> will report the corresponding CXL general media or DRAM trace event to > >> userspace, and userspace tools (e.g. rasdaemon) will initiate a repair > >> operation in response to the device request via the sysfs repair control. > >> > >> 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. > >> > >> Signed-off-by: Shiju Jose > >> --- > >> .../ABI/testing/sysfs-edac-memory-repair | 244 +++++++++ > >> Documentation/edac/features.rst | 3 + > >> Documentation/edac/index.rst | 1 + > >> Documentation/edac/memory_repair.rst | 101 ++++ > >> drivers/edac/Makefile | 2 +- > >> drivers/edac/edac_device.c | 33 ++ > >> drivers/edac/mem_repair.c | 492 ++++++++++++++++++ > >> include/linux/edac.h | 139 +++++ > >> 8 files changed, 1014 insertions(+), 1 deletion(-) > >> create mode 100644 Documentation/ABI/testing/sysfs-edac-memory-repair > >> create mode 100644 Documentation/edac/memory_repair.rst > >> 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..e9268f3780ed > >> --- /dev/null > >> +++ b/Documentation/ABI/testing/sysfs-edac-memory-repair > >> @@ -0,0 +1,244 @@ > >> +What: /sys/bus/edac/devices//mem_repairX > >> +Date: Jan 2025 > >> +KernelVersion: 6.14 > >> +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 >name> > >> + directory corresponds to a device registered with the EDAC > >> + device driver for the memory repair features. > >> + > >> + Post Package Repair is a maintenance operation requests the > >memory > >> + device to perform a repair operation on its media, in detail is a > >> + memory self-healing feature that fixes a failing memory > >location by > >> + replacing it with a spare row in a DRAM device. For example, a > >> + CXL memory device with DRAM components that support PPR > >features may > >> + implement PPR maintenance operations. DRAM components > >may support > >> + two types of PPR functions: hard PPR, for a permanent row > >repair, and > >> + soft PPR, for a temporary row repair. soft PPR is much faster > >than > >> + hard PPR, but the repair is lost with a power cycle. > >> + > >> + Memory sparing is a repair function that replaces a portion > >> + of memory with a portion of functional memory at that same > >> + sparing granularity. Memory sparing has > >cacheline/row/bank/rank > >> + sparing granularities. For example, in memory-sparing mode, > >> + one memory rank serves as a spare for other ranks on the same > >> + channel in case they fail. The spare rank is held in reserve and > >> + not used as active memory until a failure is indicated, with > >> + reserved capacity subtracted from the total available memory > >> + in the system.The DIMM installation order for memory sparing > >> + varies based on the number of processors and memory modules > >> + installed in the server. After an error threshold is surpassed > >> + in a system protected by memory sparing, the content of a > >failing > >> + rank of DIMMs is copied to the spare rank. The failing rank is > >> + then taken offline and the spare rank placed online for use as > >> + active memory in place of the failed rank. > >> + > >> + 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. > >> + > >> + 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 device physical address(DPA). The DPA and other control > >> + attributes to use will be presented in related error records. > >> + > >> +What: /sys/bus/edac/devices/ >name>/mem_repairX/repair_function > >> +Date: Jan 2025 > >> +KernelVersion: 6.14 > >> +Contact: linux-edac@vger.kernel.org > >> +Description: > >> + (RO) Memory repair function type. For eg. post package repair, > >> + memory sparing etc. > >> + EDAC_SOFT_PPR - Soft post package repair > >> + EDAC_HARD_PPR - Hard post package repair > >> + EDAC_CACHELINE_MEM_SPARING - Cacheline memory sparing > >> + EDAC_ROW_MEM_SPARING - Row memory sparing > >> + EDAC_BANK_MEM_SPARING - Bank memory sparing > >> + EDAC_RANK_MEM_SPARING - Rank memory sparing > >> + All other values are reserved. > > > >Too big strings. Why are them in upper cases? IMO: > > > > soft-ppr, hard-ppr, ... would be enough. > > > Here return repair type (single value, such as 0, 1, or 2 etc not as decoded string for eg."EDAC_SOFT_PPR") > of the memory repair instance, which is defined as enums (EDAC_SOFT_PPR, EDAC_HARD_PPR, ... etc) > for the memory repair interface in the include/linux/edac.h. > > enum edac_mem_repair_function { > EDAC_SOFT_PPR, > EDAC_HARD_PPR, > EDAC_CACHELINE_MEM_SPARING, > EDAC_ROW_MEM_SPARING, > EDAC_BANK_MEM_SPARING, > EDAC_RANK_MEM_SPARING, > }; > > I documented return value in terms of the above enums. The ABI documentation describes exactly what numeric/strings values will be there. So, if you place: EDAC_SOFT_PPR It means a string with EDAC_SOFT_PPR, not a numeric zero value. Also, as I explained at: https://lore.kernel.org/linux-edac/1bf421f9d1924d68860d08c70829a705@huawei.com/T/#m1e60da13198b47701a4c2f740d4b78701f912d2d it doesn't make sense to report soft/hard PPR, as the persist mode is designed to be on a different sysfs devnode (/persist_mode on your proposal). So, here you need to fold EDAC_SOFT_PPR and EDAC_HARD_PPR into a single value ("ppr"). - Btw, very few sysfs nodes use numbers for things that can be mapped with enums: $ git grep -l "\- 0" Documentation/ABI|wc -l 20 (several of those are actually false-positives) and this is done mostly when it reports what the hardware actually outputs when reading some register. Thanks, Mauro