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 9A5D6D3A67B for ; Tue, 29 Oct 2024 18:32:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 097876B007B; Tue, 29 Oct 2024 14:32:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01FD76B009A; Tue, 29 Oct 2024 14:32:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB4046B009B; Tue, 29 Oct 2024 14:32:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BA9BF6B0099 for ; Tue, 29 Oct 2024 14:32:56 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6221CABF49 for ; Tue, 29 Oct 2024 18:32:56 +0000 (UTC) X-FDA: 82727485890.11.A46B8AF Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by imf29.hostedemail.com (Postfix) with ESMTP id 43B8E12001F for ; Tue, 29 Oct 2024 18:32:20 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mIV8UixH; spf=pass (imf29.hostedemail.com: domain of dave.jiang@intel.com designates 198.175.65.14 as permitted sender) smtp.mailfrom=dave.jiang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730226693; a=rsa-sha256; cv=none; b=ZRt3sstOTVJ9Z3Nw0P+NBdslRAZWOLoFkMyKdPiuRNR1vxkb7epR0FlSchXDEya90iLhNL ognXcnR4zqAZUgTkwDRIXgfpL1NGalN2hg4jDt+GfqUaJR8CQ/BUSBOQAZS0ZRzEbzbLRI M8Q4+m2fnH8UeeNCSOibJFfUdkf+s64= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mIV8UixH; spf=pass (imf29.hostedemail.com: domain of dave.jiang@intel.com designates 198.175.65.14 as permitted sender) smtp.mailfrom=dave.jiang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730226693; 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=yaGmXeuXWosgbDpYnKkqr1Kptig68zrg3DEg39ahhb8=; b=U3jH2+SDLL6+9aEJjkjO/yEnQewcBn8X0bTKY/GIeesBajMK2kO6M/fVrfB5ubJfDhMalT RytowMu00c9PA9mgcehARUFku5f27lKHi3OBaxfj15LIEfFGPQmCa/9u8wBa3onm68TQ/j 8NqKHM81v3AWm0eGjTuoseYUdkXPNbs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730226774; x=1761762774; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=2iCf5LaYMYP0f6vDDdCjb6d/lEtrQIo0CxHWClhvTwk=; b=mIV8UixHdkJ5sK/NPl539HDho4yhiBlS94SH8qGuhbxzFbnD4NibsBYk xG6fnI8MahWZFXwOfuwHIK9WfcPuCtzC5bO1EcWREb8QX2WGxMxSk63jJ psh1ZiGV4hJzQmiliEJYbDwV/AiGk+nyfGmPD1p2BRLa+GnGR9l9Hn0cb Npoye708HE46M+NqnAMcJpPSOwK05rceEZyVAdhDsBriaYsXtivwVLX51 PI21BjWDZn6YEhd3YAzgFibHfDHVxkv7xmA0fBgY/uanxnhApB6g/WNuh IhS+NQ7bupxeAnbgO8sR7xroGJkC4aiistJoY1tDp+oLNgLIsbVom2/08 Q==; X-CSE-ConnectionGUID: ZCBD9wabQ7Kg1F9KNPAsvg== X-CSE-MsgGUID: QZ1GfIs0Qpaxmm8qIrFplA== X-IronPort-AV: E=McAfee;i="6700,10204,11240"; a="33685471" X-IronPort-AV: E=Sophos;i="6.11,241,1725346800"; d="scan'208";a="33685471" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2024 11:32:52 -0700 X-CSE-ConnectionGUID: QUD7wlVIRaeHgKopSSyAiQ== X-CSE-MsgGUID: +5zIdsocS/GhuVYEbXDLfA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,241,1725346800"; d="scan'208";a="112856060" Received: from rfrazer-mobl3.amr.corp.intel.com (HELO [10.125.108.71]) ([10.125.108.71]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2024 11:32:49 -0700 Message-ID: <67b569b0-1cd5-44e0-8465-064b41a1afd8@intel.com> Date: Tue, 29 Oct 2024 11:32:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 07/14] cxl/memfeature: Add CXL memory device patrol scrub control feature To: Shiju Jose , "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 , "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 , "Zengtao (B)" , Roberto Sassu , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm References: <20241025171356.1377-1-shiju.jose@huawei.com> <20241025171356.1377-8-shiju.jose@huawei.com> <3a007a70-136b-4a45-8dd2-d33725ea96bc@intel.com> Content-Language: en-US From: Dave Jiang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: hr8sudn7qffewag9gxzp148nk3hcdob8 X-Rspamd-Queue-Id: 43B8E12001F X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1730226740-411147 X-HE-Meta: U2FsdGVkX1/5TUN+zFFOIQy6x3ADVp+oGxYMyFgtZL8IBC9xZqb0zlc51qrILsx1EFkAx2Z+hA3LQ4+OCtzbJqtJBn5QYWYytC4etUATighso801p6B3juDzBQ2UjEF/rxEB/VwzlnvDvP3xYD9oTNEJOrae44i+TZ36fnWZjxcdJXxMlfK9KAzUbdCMOd6cM4ipfVzcUrxw8NBCo8v3Kn1oDM8Bx7Y8fReD58tTJS9TIMuizf3ox8rr4zUH3PtybZfYxM4zOO8JVDkFPkaTnWydH6x+5UcJrNJni9LB4fGF8MRv4DFa+sahLVUYpE9ohI+f6iMdw3LKmvS2/pKeZo+/g8uzfXBZ5EzadmzNXH6DBVRrrzVO4MgvtnifMXTT5Q6AvmAgYTX4w7F4kHFrQ//Yn6NaXcihlUE7QN2XwEAvSnse7/3aVfPP9XffEOiRpblkOYXJETZjvUwvE4PUac2QaK3V/ZPw9NLA2ry+7FPv0oQMYWfVQPoAUNen3MnTMnzDtK1NoW+e29htlsU6osgZuDFgT0DJwrYlo6btxlueuRN+enfIpscTzJO8laN1sKkAxUB69eFspRFa/CD4/XXO6jNwKJR7HLXlLhTdA3yaPea1R2/oWkdXmRI158sCWKuZ+dfmV3bIbs9uENM/8dNZHoTM7DopeEuERhTaPv3T1uD5PZEl5dY6HlEcoYJk5O7krmLcvmNgNkniFFbPdDILAOpiYDTeigECh83D5I1zyjthjseTjhakRQgw04JwIlYFYeIoMgF09zqCs7hEikPeoc3M93etBTPRJHDFSeilkRNZrVPeQn53EIAKQEynXOVPHOFBNICiOGrTcR1UMv/ulF/u9sYSHphziYFtix9Sp/RS2dLFsgX9Vqwx+gRr20nsKiPR42Af0gIVBK97nXvwZtSXulWL9l6gm4S7pV4U2AYd5s86qpmlP/4MA2nsFbrud5HmT2okbquiNdQ /98dLhod pWEcoKFs1KzSKIDIft1yeCQlmvndDAgATaLy+xFCinqTtK32wkQ0o3hOd6SHyZAQC7aMJuIx0ZUYu2nbW5bSlCjk/BidwvXUDzlo4ncRU5Yt1/GY9xamCZ1fpKSxqxODn4HlBJrqcRNezmyVP7ro3FEqvXzJF73qt2eWgxyTeWYeINSWQ82EPE2qgKontpBB/6bDJwOAhIuLe+46KXDt9F/SiVdNwFCrronbvGqBn4mM4rmEP70yCxLTrpUbXemV3fRcoxAQIcibknljG8N4Eiz1gqcTx8FN+SGKqHrFZICH9HyyO4f3VZEutcCBKjQvDTya25nEt2zgii6KE9OO59OJ9T3StVSCH7B5x/uecTrLmsa7sYiwdTYNVlbOkW+GmkSLNCt6Z1Qt7IVId3i7iqWFid1bNoo6SGC2Nb9I6G33FC9PhBcVdDL9/xKe3wrRA74UKVQMsLiDIrwQgQMZM8ckc0zaDOrGjWpL2EN5vk0RipQEW/uCKPeSjYkwmHW+mcNCEv6OqMmQxBfvTXa1hPV3hZ2F8kcoyYz2WEZRu5buSmXeUSYv4osTAHamNSVSXLSywDVwh7t54c2m0GuG5hBl8Z7L8CaRE8R+imVtGjwAn+52Q+dv3vR5ItsGmYEHAjryLc14XL34yUvAdb4IGKllTskiuhaOwse2S109P3OTYP5cbz9R1wNUJQOC6LrareyFnCE/XbNYpnc7DWu+suX0tau94/ABjoTrJ5HhZ+b9h+xh2NeiY4QIzuTUfJCMDFjeA9Wht9O3UYNUaLD1Fh+pZiqwTogImACyenhybVEXOXmi0oo6UC1+hpSSOTEnAtsclKD7Nz2nJm3CV2PBzi+hnY6KLomPjSGki5dDpBHzBun7n1TzmdAjLFJ/B+q3YF+0EX5RVmmFcoH5tdT7QY/cy2u8L04EjdB4tgYMsSrOdUyDtyZ1FqdLRRg== 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 10/29/24 10:00 AM, Shiju Jose wrote: > > >> -----Original Message----- >> From: Dave Jiang >> Sent: 29 October 2024 16:32 >> To: Shiju Jose ; 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 ; 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 ; Zengtao (B) >> ; Roberto Sassu ; >> kangkang.shen@futurewei.com; wanghuiqiang ; >> Linuxarm >> 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 >>> >>> 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 >>> Signed-off-by: Jonathan Cameron >>> Signed-off-by: Shiju Jose >>> --- >>> 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); } >>> + > [...] >> >