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 037B4D6B6AE for ; Wed, 30 Oct 2024 16:46:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CA9A8D0005; Wed, 30 Oct 2024 12:46:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87BC68D0001; Wed, 30 Oct 2024 12:46:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F4EB8D0005; Wed, 30 Oct 2024 12:46:28 -0400 (EDT) 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 4FFBD8D0001 for ; Wed, 30 Oct 2024 12:46:28 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0AB2BC0E6C for ; Wed, 30 Oct 2024 16:46:28 +0000 (UTC) X-FDA: 82730846310.16.2BBB517 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) by imf26.hostedemail.com (Postfix) with ESMTP id A590214000F for ; Wed, 30 Oct 2024 16:46:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=aKq3cCm8; spf=pass (imf26.hostedemail.com: domain of dave.jiang@intel.com designates 192.198.163.11 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=1730306627; 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=yzMvsHJroKuhrO5ccyIi05xnjxzjvP/Xbrjxsalnf5U=; b=tMKqPgpAroFPYJqTHE13iGivWDNSgG3mvE7HbpmAVjnwRbk0MjkA/Biq32/Yl4/13prybW 913UW+Hp4YzbiGNN8K7hooKfADrxAdcQW+p3DXNaHkhden5rMqQNau0hzy0UnmgjNnNDnP Hb1SE0C/8SoOEggOyoDNP1lUGCO3INs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730306627; a=rsa-sha256; cv=none; b=DvIJpOnFSVyZP2tq0yTQ6eOShUFfzM4fKrUjlkkkM8pd0sF/AWY40YjRdBbL2UwGt9iF6Z wKukXfgAuY+IXa6OgcmsD5LP7BJ7RlCF9DjjpKvsmDc9ucprBvlAnFTHsU8SbD1TtF3lRP L5bqicSwvHQNnolGKHJKeQJYrYeBhKw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=aKq3cCm8; spf=pass (imf26.hostedemail.com: domain of dave.jiang@intel.com designates 192.198.163.11 as permitted sender) smtp.mailfrom=dave.jiang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730306785; x=1761842785; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=kkCKvFjpUCVV69H1kfwrpgpFazlpD0ZkPP3c2tJJ1tg=; b=aKq3cCm8Qfyofv33tOobtuPqk5YsKVORGziaV4oWSBf8dui+2O91IGaY ee46XxOcXqwgoRDtm26mD85D3we3JWPgJNAJwgZwCM2f62prThR3p3Yk+ CwFSCsTh6gUPgG2i+ixnGxnuDQxxLxGl7SzKaFSMguKFdJ4wzm67zSjhi 1s0WAvX3srLrIV1dia1uPWCpk4pz53XQHVLfq+uwNKlxNB2as4NtvsQA1 mnvZUTc45IY0GQD5TCRDirIRtuvGRrKKdjfJ2NM7zb/9p7dHzwbj6P9Dh y/dNHnCzaZ8t0LuAv4ETjWu1zCIPq5GRibnu3SD7PtVFRbAZZw351Ufdx g==; X-CSE-ConnectionGUID: CnDeC9cNQBS1wLHCZL+KxA== X-CSE-MsgGUID: JDku7AxZR+qp0/psXBHsGQ== X-IronPort-AV: E=McAfee;i="6700,10204,11241"; a="40592505" X-IronPort-AV: E=Sophos;i="6.11,245,1725346800"; d="scan'208";a="40592505" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2024 09:46:23 -0700 X-CSE-ConnectionGUID: yB+rFLQpRhmf61Ein+LMbw== X-CSE-MsgGUID: FAVjUsqvTqeuOf+OyGtp+Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,245,1725346800"; d="scan'208";a="87150911" Received: from nnlnb-sb-019.ccr.corp.intel.com (HELO [10.125.108.160]) ([10.125.108.160]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2024 09:46:17 -0700 Message-ID: <35faf0e5-9f54-44e8-ae65-ce1dc91b9cbd@intel.com> Date: Wed, 30 Oct 2024 09:46:16 -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: Jonathan Cameron Cc: 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" , "bp@alien8.de" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "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> <67b569b0-1cd5-44e0-8465-064b41a1afd8@intel.com> <20241030161628.00001fdc@Huawei.com> Content-Language: en-US From: Dave Jiang In-Reply-To: <20241030161628.00001fdc@Huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A590214000F X-Stat-Signature: 9geya8k4zce7xfbxikjm9jxpnos6pg6g X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1730306765-300083 X-HE-Meta: U2FsdGVkX1+E0HuKOIjC401OTCVPPUwzjB0+y0F6pp15fwtRKS2Nybi/BxjYYwnaPeYhKN/lsR8hnwgPg/RE7Wm+JnC/kuWn8zEIntXydZCa6Wb5+faaIcc80fPmMm/K3mldionKiM9j7AZqdw7jirZvdVvlhzo2vcGRr53RPwCwIh4WZr1rkeBVWfWFjH9H5ym6HPI8Fj92joZ/qqHlCKxo3oOBHE46CLz+2Gt/7bsp317wsm6kfGYoX1H+eNHgNpgByMOgy7GWQAG42PK68VDEB++VrLLkALzmG4E6zVefTitKUEltKVIaUpgz2pAraP2xQqh/c4v6y2TgzNSnTkKSYQQOz2on2JhbAmPZ4gc1J7swhOqovHX6Yn3EF8lSl1iEdLumhoxPStpTE5xByaoEzxDqUwdssp454rB8Xgf4IXG3E1ZxlURmImnNjILgjjsYNJiNOTCJId+DxB+q1SIQ4OSe4dSa8Q9HVfVv9GquHG/3MAS0S/rAdltGJqJbPOmxu79hVbKfOB7r/xFH9G14VTnOg22pGVPa2KvDhMSQAMSg39ZZ/1RaiCM7iYGPMxHueA2Ub3ruVkBmF92a+nKyUE9KcyTvllBjlA2+2J5/xSQ1dYNIZfo1dgRM8+ilFXrnDneRtyfWJmw51OT/m7wby/3EKnCrLHfwcJ3vKirBBzbzkohxQ2Z1aifMoP5XZQLr7K+nze0ytbIYsb5FMLLqfSQg5lAXhzRHIJvwg+VLNXpMaDr6iCrBA4yj2NXsX1uzK4ahzgMbQUtSBj4CQ1dAY2Si1M+yJ+cUkP/e6f1rkqgrh0DHsJmpTs9tnKXER5WcWe/0m+FwZ9ErrExJ70c2VDBMUrBu4LWEfU7WP1a9+neztr906Z4QUAslmfNaKtorHL4df8LHme4NwD11BCDSai2d8/4WgvkJdeRInj7AgjsI8AyQamtd+WrdcnojSXo8hwz1Bgch8JQgz0Z F/92HTqj 3K/hIHaMviazWQhJVlp+cYcGxw0eNOgsCUWyuw9JcuKyBqNC88pZ+OgbB95B4+P3q7N+n/2fEKPPYILovWFzNqV+Vmz/T+DV8AUElXZ+4Z26yYljZde5+iJqoXVZkp6FOVFiWizsKFooiQml/04yg3/umKHn0UrEO9FA4cG9YM6IJnPvWtDy5iKby7liHW7JiH4rWafokzWIkZ9fH5RB6urAZtcL1h+0SR24GIwGo2PrQyXjQMGOoJ89D+MFDnKn1UBaP4lSMfXltzVqMKI63BGH2yzhuFGigC2l2rMsrFlI+c6FhFgy9ZbIc5vof54Lzt4KR3BopiygmUnPDsCXgpEnXvbrPvtv2N0LAXCse220pAdlQcfInw/uYf3cUbazeqxgF3z4qhGZ8jYa74b92IpgrvFtDrFjbTp/STGCETEaSyU22Xxcwj/rJ/5xoDfX5q/lqw5tTlu8kRmsUZt9+ai1DHlUI4mj+WjpA/G8nxOmwBQ37KdpGX4BBO+4GjnyflmpT6zviaXKDoEBj+685YYFNXef6bcA2z5+5BZ733O5yjMwn+x1pKHeYiZwhQvuYy6mILRSBC1gk13PDeEmcDhU7oR+BnAVE10IM8Nl8/DDFVfmx3OymoPLEFxL0yYur65wSOP1gxhakIBnuZ2s2v56gZts70IIw/Afqax86FJMmqploYiqWb/AvrMxME1HPjvQykU2O0C6BUISUlxJAA7Brcfveb4UIiT7DlI+TIi/Bzh07s55kksFP+b73TpZqgTNjVdZXo9gfAHMo6if+CtQfRbKZp9lL9bY3zfo/9Soz1x5ZOinWimY2pYSa/uXfq6W77lMit2n8wBuNz84Rnegzrr87dJokLRwOVvCZxMnC9QpV8kEPUUd1U4IUCNchjJSVYtXtS+LXrBm03KkOQo0HUg6lqueSmvBLVJvB8jck+X1vngTZJ7yBnw== 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/30/24 9:16 AM, Jonathan Cameron wrote: > On Tue, 29 Oct 2024 11:32:47 -0700 > Dave Jiang wrote: > >> 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. > > You could but then every new driver would need to include > changes in the edac core to add it's own entry to that union. > > Not sure that's a good way to go for opaque driver specific context. > > This particular function though can use > a struct cxl_patrol_scrub_context * anyway as it's not part of the > core interface, but rather one called only indirectly > by functions that are passed a void * but know it is a > struct clx_patrol_scrub_context *. Thanks Jonathan. That's basically what I wanted to know. > > Jonathan > > >> >>> >>> 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); } >>>>> + >>> [...] >>>> >>> >> >> > >