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 63D32C10DCE for ; Fri, 8 Dec 2023 13:48:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E56046B0082; Fri, 8 Dec 2023 08:48:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0E1A6B0083; Fri, 8 Dec 2023 08:48:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF4A76B0085; Fri, 8 Dec 2023 08:48:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B8A176B0082 for ; Fri, 8 Dec 2023 08:48:37 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9049D80217 for ; Fri, 8 Dec 2023 13:48:37 +0000 (UTC) X-FDA: 81543781074.29.47DADA6 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf18.hostedemail.com (Postfix) with ESMTP id 3FF611C001E for ; Fri, 8 Dec 2023 13:48:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702043315; 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; bh=tNQzQcxLycis20bmFaOmmm+qV0KJyOSeDn/BEoCN97A=; b=41LYHzeEQHtUY5rg2S0U/S49ygeMdufyb/izrJOKResJXG3Kp2Y6twKI4SXztGILuVdFNe wLr1w4/qjIZJw09BnVT+DEraIqUp8b4kGDWqeotI7bn9MCFftwjWQIgSToZxMpZHNovCL4 IrQsDGrm3ZyjNG5z2Qzt5qsl0jomcFo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702043315; a=rsa-sha256; cv=none; b=O4DYLvkm344LUwUIupxS+z9Z6iboLbkPTNxO0rggT7UTAL4yS5mPrXtSGKREZbxaFdOIfZ s6auho9dWR3AMzXO3MkF0+kSBJunm5TrP6P/nhYEsb4X1R33324VEOXSxEWBkd0qdgxDVT 74Bdl58A7QvDn2LxlT0Xo9D8Lcuh9YI= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SmssF151cz6JB1X; Fri, 8 Dec 2023 21:47:45 +0800 (CST) Received: from lhrpeml500002.china.huawei.com (unknown [7.191.160.78]) by mail.maildlp.com (Postfix) with ESMTPS id 9394D14011D; Fri, 8 Dec 2023 21:48:30 +0800 (CST) Received: from lhrpeml500006.china.huawei.com (7.191.161.198) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Dec 2023 13:48:30 +0000 Received: from lhrpeml500006.china.huawei.com ([7.191.161.198]) by lhrpeml500006.china.huawei.com ([7.191.161.198]) with mapi id 15.01.2507.035; Fri, 8 Dec 2023 13:48:30 +0000 From: Shiju Jose To: Dan Williams , "linux-cxl@vger.kernel.org" , "linux-mm@kvack.org" , "dave@stgolabs.net" , Jonathan Cameron , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" CC: "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "tony.luck@intel.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , tanxiaofei , "Zengtao (B)" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: RE: [PATCH v4 00/11] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Thread-Topic: [PATCH v4 00/11] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Thread-Index: AQHaI8KwgMGD3E1NJkm1EO0u0hTVFbCcsBMAgAJ2I3A= Date: Fri, 8 Dec 2023 13:48:30 +0000 Message-ID: <9bc4b5fac46d4f37b675de4e0f65931b@huawei.com> References: <20231130192314.1220-1-shiju.jose@huawei.com> <6570cdbaa96e0_45e01294e0@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <6570cdbaa96e0_45e01294e0@dwillia2-xfh.jf.intel.com.notmuch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.159.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 3FF611C001E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: d34is38m1kdz8kg6pg5eyfb547xraqkz X-HE-Tag: 1702043314-88602 X-HE-Meta: U2FsdGVkX1/Bw0OPz3Xx8xRr3gF3xz/2Fa7U21Q0czyA6Nverey9kdfUgCp+2hS9lWzDhV7tZoYIyOdSHso42Zcev0PfZaH3BFQ/8wl7tee+o/lBduV/uNChfF8poOzwKBeP+63GSInxhEO0KNKHOx8lC+GguB7uyvo7D1lmsjHNemWuZIZ5PnnPhM4G6Prr+9xyfdLw8tt7fQtTGPvw8fhRsZXRgV8Ld2/QIL2FD+7AdLF2Dt83digCxKuI70aIDdkwPK7iDoI6X5GOHG5tsB+KFgq7eJHX+Lej5Oa3m63Kf+njT9hTzAZd7ZT+Uc370EKb5X585ZMmDnWkS87jGf5/+QAnHMP481fonUrqjegRv8+SrshS5ZD9vGfhDkKixdbSnd2Z10pOzwxAQJRMRUOxxpmCo68Uo2NH6+pum8/5M1Yp+3EpmTTonfSozA/mHAOn7BuQGRmE+aX+DjW07jnixHZd+BsTQBHkVfsyyrcCTdDxmTIMQ8Wk9xDIOO5EZgg0QMzMvXqfda+40pw4QyuB+TLYs8JD1EI6nP6LB+Af8LyV9l8u/psh79XePIBayAgDHFawJtpcFRf0j4MWrNE8qqeoEd2mgow8jJVl8afp6fAf1ZYs06iVKt/+0FQHM+VlU8WFHQFAgNc98J8/JWAH4UdS9EBZ4NSloSde/vLRP+MhhG4SuiPWzHwQm5SPEse+/I2XGE3xSf18p6nX1/olUNLj5C8BF7IhfWRTcflKs8KTiiWA5UkJCWqL1qUSaBMNcw6t+RC0hwYA/b8JsAaAAP0EuOcLqTATEqgA3Usjk/qmwQohoPNs/zFsYgo8fDwVk9k8aIYehkt6dACuczuVshA+EYHC1ymiunlXJUWC3M8/M7Rt2PP8PWKJ9rZatDhw2fZ5KLFTp/6O2ZZsn2jUTpCMiVaKBCg72I2EJ8fwkooE+WAV/OX6JwoM0iqWmPd7vK+G4VYVMK/bvaE maOIcWFm 4dsrDM4e4byMzG64f6YcgywFan6Q4dMQaMvRCAR6ArGFqDcR7YAOc3oSBqyygGJOY0QwNFoiG0Jrs+PnXV5nfOzdcBCeXpUaBX+tCl3EBvUDIO9cw9HH7fKbs27KIjwSkRkx3lzBw8sQPGm9gt2Kc7YUjd4gqNpNfD/5kTWNWthiDDphJLfKDLqsJdjxvKBJ6wlXwQmyaqcNndZUW8TIgxnGc+VRbFAKeG/jowLFtC/AZSkd9kglYp1fXSYYalZ9TqBpMxzZ1pbMPvs6V68YgahW6Xzh4uUOBqAgHOu8AexDh0piFF/InqEVc7Y1jnuGKSalQvH+K5sRN3rjKRP7d3P+mjcOVOuDS3mBIV91nqhs09OAcE2cVhjoLxbknhqG4/D/k3JzYOWxi2uim9nw7xWX9uJN7iPn2/b3p6e8hdJXnzoDfaO4LB/IMeZEy1CI4fr5IUy+xiITulbkpSjPlUC2ImNvTEakbilyNaTPLlx1MaFwiolrhOCaMna8Xb1IXS7vTzarr0oCDZIljI1mNror7s0OSBiyQu04q4LZDIE44Wnckg2lQk5U47OFKqPCyHV1iIGTAH9oxqwLA77Z53OaXZCjazUiXS7Qv+ydm2NeKg/yVPAdf/wGPaGVoWFICLNzO8GXpjtCaQoMzvXfzWqIB5nSnVVXMVVa14eqrrF9vjyfIUZCDaHEJkgkRQmyY7YkGGiqo7C2LY/lUUnGJ+g4c2oPd3RCzw/jKHJgDJIP/hKxQJtL+0HnZqnuRLTaH82cAIGD4gxVHd9+UU0rBPXxebQ== 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: Hi Dan, Thanks for the feedbacks. >-----Original Message----- >From: Dan Williams >Sent: 06 December 2023 19:39 >To: Shiju Jose ; linux-cxl@vger.kernel.org; linux- >mm@kvack.org; dave@stgolabs.net; Jonathan Cameron >; dave.jiang@intel.com; >alison.schofield@intel.com; vishal.l.verma@intel.com; ira.weiny@intel.com; >dan.j.williams@intel.com >Cc: linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org; >david@redhat.com; Vilas.Sridharan@amd.com; leo.duran@amd.com; >Yazen.Ghannam@amd.com; rientjes@google.com; jiaqiyan@google.com; >tony.luck@intel.com; Jon.Grimm@amd.com; dave.hansen@linux.intel.com; >rafael@kernel.org; lenb@kernel.org; naoya.horiguchi@nec.com; >james.morse@arm.com; jthoughton@google.com; somasundaram.a@hpe.com; >erdemaktas@google.com; pgonda@google.com; duenwen@google.com; >mike.malvestuto@intel.com; gthelen@google.com; >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; >tanxiaofei ; Zengtao (B) = ; >kangkang.shen@futurewei.com; wanghuiqiang ; >Linuxarm ; Shiju Jose >Subject: RE: [PATCH v4 00/11] cxl: Add support for CXL feature commands, C= XL >device patrol scrub control and DDR5 ECS control features > >Hi Shiju, > >I have some general feedback at this point before digging too deep into th= e >details: > >shiju.jose@ wrote: >> From: Shiju Jose >> >> 1. Add support for CXL feature mailbox commands. >> 2. Add CXL device scrub driver supporting patrol scrub control and >> DDR5 ECS control features. >> 3. Add scrub driver supports configuring memory scrubs in the system. >> 4. Add scrub attributes for DDR5 ECS control to the memory scrub driver. > >For a new a subsystem that is meant to generically abstract a "memory scru= b" >facility the "DDR5 ECS" naming has too much precision. How much of this >interface is DDR5 ECS specific and how much of it is applicable to a theor= etical >DDR6 scrub implementation? > >My primary reaction is to boil down this interface so that only generic sc= rub >details are visible in the ABI, and DDR5 specifics are invisible in the sy= sfs ABI. Sure. I will check this. > >For example the Linux NVDIMM subsystem has an address-range-scrub facility >that is independent of the specific memory technology scrub mechanism. Tha= t >one is based on ACPI NFIT, but I realize you also looked at enabling the A= CPI >RASF scrub interface. It would be useful if this patchset could plausibly = enable >one non-CXL scrubber along with the CXL one. Sure. I will do this. I will add ACPI RASF scrub patches to this patch set. > >> 5. Register CXL device patrol scrub and ECS with scrub control driver. >> 6. Add documentation for common attributes in the scrub configure driver= . > >Going forward, please include the Documentation in the patch that adds the= new >ABI, it improves the readability / story-telling of the patches. >It also makes it easier to analyze which code is needed for which ABI, and >whether a given ABI is justified. I will do. > >The regionY nomenclature in the sysfs ABI looks like a potential opportuni= ty to >align with the "memregion" id scheme. See all the callers of memregion_all= oc() >where those are tagging device-backed physical address ranges with a commo= n >id namespace. It would be great if the memory-scrub ABI reported failures = in >terms of region-ids that correlate with CXL, DAX, or NVDIMM regions. For the CXL DDR5 ECS feature, presently the regionY corresponds to the IDs= of the memory media FRUs (1 to N), defined in the DDR5 ECS Control Feature tables= Table 8-210 and Table 8-211.=20 =20 > >> 7. Add documentation for CXL memory device scrub control attributes. > >Do the CXL specifics need to be in the ABI? One thing I missed was how the Ok. I will remove. Should these DDR5 ECS specifics consider as generic and= =20 be part of the memory scrub ABI? =20 >series of log entries are conveyed. For CXL in contrast to what NVDIMM did= for >address range scrub is that CXL makes use of trace-events to emit log reco= rds. >That allows the sysfs ABI to remain relatively simple, but the various tra= ce- >events can get into more protocol specific details. For example, see >cxl_trigger_poison_list() and >trace_cxl_poison() as a way to genericly trigger the listing of a flow of = device- >specific details. In other words put the DDR5 ECS specifics in the trace-e= vent, not >the sysfs ABI if possible. Did you mean remove the readable attributes for DDR5 ECS from the sysfs? For example the "ECS Threshold Count per Gb of Memory Cells" and "Codeword/= Row Count Mode" in the Table 8-78 DDR5 ECS log of section 8.2.9.5.2.4 DDR5 Error Check Sc= rub (ECS) Log. =20 > >Lastly, dynamically defined sysfs groups are less palatable than staticall= y >defined. See cxl_region_target_visible() for a scheme for statically defin= ing a >runtime variable number of attributes. >Specifically I would like to see a way to define this new subsystem withou= t >scrub_create_attrs() and all the runtime attribute definition. > Sure. I will check this. >Overall, I like the general approach to define a common subsystem for this= , and >get off the treadmill of reinventing custom scrub interfaces per bus, but = that >also requires that it be generic enough to subsume a number of those per-b= us- >scrub-types. This is the challenging part to make the scrub interface generic because th= e scrub control varies between the scrub types, for example as seen in the CXL ECS. Thanks, Shiju