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 1CBA6CD37B0 for ; Mon, 18 Sep 2023 12:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFD8F8D0006; Mon, 18 Sep 2023 08:29:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AADBB8D0002; Mon, 18 Sep 2023 08:29:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99D6A8D0006; Mon, 18 Sep 2023 08:29:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8B1248D0002 for ; Mon, 18 Sep 2023 08:29:09 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 495FC8034F for ; Mon, 18 Sep 2023 12:29:09 +0000 (UTC) X-FDA: 81249648018.20.EBAD747 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf25.hostedemail.com (Postfix) with ESMTP id 30609A001E for ; Mon, 18 Sep 2023 12:29:05 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695040146; a=rsa-sha256; cv=none; b=kWU3HtoOAnTORJMH0x1jWhDb10J8nZeiNpfugu65FBXYFC2Lkg0CEFqoIhqJOjtXBnge01 oUsC1W4cVGj50BcKmFqAzE881uP4LSnCCHD9Nb/To+v/hXgSAVrQwJQwoUr6V5JedbGmP7 rjGqts1b7FVBaCJ032TwPBywtCsY/Mc= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695040146; 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=4F5xJfEJYQCXyjUbI7F4le0rrzraQx4MBySwNhAJbOE=; b=g5AesuFxFMcIwbb7DRJVfILcacO1rLJdG3rzxpDDPacHBVo9mUC/10k4tEMLpBR5/U4319 bQt5ZYRR0kaEm8NoHhOdzD1p04fQ4lAOIBGGf8y6KNbBuWr2s1CPkXfBsVkGq+vkTkN0Mo 77zqGK4fAsxCVki9EnxaM6mr1w0FdP8= Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Rq3wq4mn7z6K6Qt; Mon, 18 Sep 2023 20:28:11 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 18 Sep 2023 13:28:59 +0100 Date: Mon, 18 Sep 2023 13:28:57 +0100 From: Jonathan Cameron To: David Hildenbrand , CC: Shiju Jose , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "rafael@kernel.org" , "lenb@kernel.org" , "naoya.horiguchi@nec.com" , "tony.luck@intel.com" , "james.morse@arm.com" , "dave.hansen@linux.intel.com" , "jiaqiyan@google.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "rientjes@google.com" , "duenwen@google.com" , "Vilas.Sridharan@amd.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , Jonathan Cameron , tanxiaofei , "Zengtao (B)" Subject: Re: [RFC PATCH 3/9] Documentation/scrub-configure.rst: Add documentation for scrub driver Message-ID: <20230918132835.000031b7@huawei.com> In-Reply-To: <7282d074-15ba-4fe7-bf62-6a4dd6089817@redhat.com> References: <20230915172818.761-1-shiju.jose@huawei.com> <20230915172818.761-4-shiju.jose@huawei.com> <887344ee-068d-f78f-d5f8-e816b966d875@redhat.com> <946f29d2370c41deb7a7c5a6f2bff0f3@huawei.com> <7282d074-15ba-4fe7-bf62-6a4dd6089817@redhat.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 30609A001E X-Stat-Signature: owy6s17k99rdjrqs15si865qihrkkqri X-HE-Tag: 1695040145-64445 X-HE-Meta: U2FsdGVkX18J7J77C5h9BDn/KVRzyqoHrO3vLD+e0wMu+ZTsWX2N93gH5UV8/kDJaXPE+O/yaVwLEDK2f1qWNoG0onVu0hF4C0tBtYt31Pz0EWi1S9Od86deBC29KBeCkbclqu0AH+hcqPDvMdFzF2h5d2vCWEPeb4negZcS0WKjBQWPbAPYyqz0HuapqGh6gg/mlOWsStWHr7lJpao/aY6D6chDouDjY0C5kCZNDrjaseeF2uhMpsXQj26jQjcguREssW0p2os2O9PhqgnG8S6unLQWUflYa7rIkeGqbKukCCXRv4ZpNyRI33u8aS/rSZfUqwV6ehAaCX+hkkpGJWrknN3atGuYmNGzNQ+U9TeZxeVYmtutsBjaodhJiSvlbWjeR0zHJnJi9LKaMtRPyYTNoPQjzcxs+B9PCLH+itYkGN8XJzlTOcTl3lO5zF6jv1ITW+Av9JNRESeVOv039nrDxqLI4wXQRpCfW0fMbLXFzC2gJ33H66G6lIcQF+Jcwm/3srfYWUdZALOWdL0KaipM9rAJnBy0bNJgAkYlQALBvt91lkEHBceS0dlQGTIJ+uWWAPrCHr/p6YJz8gX9VaDPSHdifoy6ubaFFVOde93fyYxbLxEymbsNZQkyV/LEGS5RA9gZ5MvmHo+RVvajWmjCV0ipcpw+2iduhBYiEaU6/JIoAEC3WLGc1A+3IWguDn5sIXkRDut2ycM6R3bhXRSv7sJQPShqUk+OSVVxYyyvMJAkcpeIuKNXN3odSRXwixfucStAiId2cAWvbNkTsj1UqXVlGfCE/1jAgp8XQF+2uMt5qZKrQ1V9kJOxNnBaWQfuQfTkVAZpi40dSb1eA6ZyksJC51XqFjUAo25c+90lSMjKlMR22urJUt8cjnwBgEQ5hazCPdwiW/lgVGsRv6K1QTXFbTG087vVq1nFGpvaCRI94gFKm4UByh+eLwhAc+f0O2DeOmVFkOWq57m hyEJOSkh CeZKdCUXxrdVeE7PVS0ySD5q8N7DajJP9OHWEduPKvb+TyW1ssMO2sGfxvu364ILj/aIJu2yxDN7Xqxe/Rva7Afjdgjp7kbCW6YOoXSJluEa92q65ibL+bQp7A+/dhRPFG2oEQmk/jYf4PHB+PQ2LH+nV8F7TsaIxFDAucTFNA/OuPz3j4qPFfTVNW5tieS3pTMGuQ52ugxDpLDy1nVFwD9dpbNT/Kys/EgPnX/21R3LqfcAtuhZ1Mw05hP5mYT3zt3LKJZCCJDgpZsCMrCCzaSqp1KCLk7Yofr4Hx+/vUVdoXAtX4zKHwKLQ8TPya/Sb3YvrmQ7C/bbqvyVnb6NhJIJSodAiP1w03V0y7cv+Ib+JbMTxhIdhE/jPJoxJj1I+A1Z/XQ5/6fx71DoLWCA9Q91OM07dXUBVf6cjv6PM1VlpFf8KStCLXTrUraCDqndwGqigdIEAXKDXFPaUKCtCk1YLmQ9WzOvOG0La2zAJGM6jf1UXK97NNOnGpBX2pJObgx6SS823TrgZApY9DnyktzCooXWDFolYNuXCyAjvhhEVBdN/4caY6ozTiVNqKFTk1E57WGhV4jY0n2e3WteON4tRJn4b2kqvaVSmfTXR3Wk/yxOl4YnVXudYH/tJNGJ1XvrRligHAsUYhDw= 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: On Mon, 18 Sep 2023 14:15:33 +0200 David Hildenbrand wrote: > On 18.09.23 12:25, Shiju Jose wrote: > > Hi David, > > > > Thanks for looking into this. > > > >> -----Original Message----- > >> From: David Hildenbrand > >> Sent: 18 September 2023 08:24 > >> To: Shiju Jose ; linux-acpi@vger.kernel.org; linux- > >> mm@kvack.org; linux-kernel@vger.kernel.org > >> Cc: rafael@kernel.org; lenb@kernel.org; naoya.horiguchi@nec.com; > >> tony.luck@intel.com; james.morse@arm.com; dave.hansen@linux.intel.com; > >> jiaqiyan@google.com; jthoughton@google.com; somasundaram.a@hpe.com; > >> erdemaktas@google.com; pgonda@google.com; rientjes@google.com; > >> duenwen@google.com; Vilas.Sridharan@amd.com; mike.malvestuto@intel.com; > >> gthelen@google.com; Linuxarm ; Jonathan Cameron > >> ; tanxiaofei ; > >> Zengtao (B) > >> Subject: Re: [RFC PATCH 3/9] Documentation/scrub-configure.rst: Add > >> documentation for scrub driver > >> > >> On 15.09.23 19:28, shiju.jose@huawei.com wrote: > >>> From: Shiju Jose > >>> > >>> Add documentation for scrub driver, supports configure scrub > >>> parameters, in Documentation/scrub-configure.rst > >>> > >>> Signed-off-by: Shiju Jose > >>> --- > >>> Documentation/scrub-configure.rst | 55 > >> +++++++++++++++++++++++++++++++ > >>> 1 file changed, 55 insertions(+) > >>> create mode 100644 Documentation/scrub-configure.rst > >>> > >>> diff --git a/Documentation/scrub-configure.rst > >>> b/Documentation/scrub-configure.rst > >>> new file mode 100644 > >>> index 000000000000..9f8581b88788 > >>> --- /dev/null > >>> +++ b/Documentation/scrub-configure.rst > >>> @@ -0,0 +1,55 @@ > >>> +========================== > >>> +Scrub subsystem driver > >>> +========================== > >>> + > >>> +Copyright (c) 2023 HiSilicon Limited. > >>> + > >>> +:Author: Shiju Jose > >>> +:License: The GNU Free Documentation License, Version 1.2 > >>> + (dual licensed under the GPL v2) :Original Reviewers: > >>> + > >>> +- Written for: 6.7 > >>> +- Updated for: > >>> + > >>> +Introduction > >>> +------------ > >>> +The scrub subsystem driver provides the interface for configure the > >> > >> "... interface for configuring memory scrubbers in the system." > >> > >> are we only configuring firmware/hw-based memory scrubbing? I assume so. > > The scrub control could be used for the SW based memory scrubbing too. > > Okay, looks like there is not too much hw/firmware specific in there > (besides these weird range changes). > [...] > > >>> +------- > >>> + > >>> + The usage takes the form shown in this example:: > >>> + > >>> + # echo 0x300000 > /sys/class/scrub/scrub0/region0/addr_base > >>> + # echo 0x100000 > /sys/class/scrub/scrub0/region0/addr_size > >>> + # cat /sys/class/scrub/scrub0/region0/speed_available > >>> + # 1-60 > >>> + # echo 25 > /sys/class/scrub/scrub0/region0/speed > >>> + # echo 1 > /sys/class/scrub/scrub0/region0/enable > >>> + > >>> + # cat /sys/class/scrub/scrub0/region0/speed > >>> + # 0x19 > >> > >> Is it reasonable to return the speed as hex? You set it as dec. > > Presently return speed as hex to reduce the number of callback function needed > > for reading the hex/dec data because the values for the address range > > need to be in hex. > > If speed_available returns dec, speed better also return dec IMHO. > > > > >> > >>> + # cat /sys/class/scrub/scrub0/region0/addr_base > >>> + # 0x100000 > >> > >> But didn't we set it to 0x300000 ... > > This is an emulated example for testing the RASF/RAS2 definition. > > According to the RASF & RAS2 definition, the actual address range in the > > platform could vary from the requested address range for the patrol scrubbing. > > "The platform calculates the nearest patrol scrub boundary address > > from where it can start". The platform returns the actual address range > > in response to GET_PATROL_PARAMETERS command to the firmware. > > Please see section 5.2.21.2.1 Hardware-based Memory Scrubbing , > > Table 5.87: Parameter Block Structure for PATROL_SCRUB in the > > ACPI 6.5 specification. > > > > So you configure [0x300000 - 0x400000] and you get [0x100000 - 0x300000] > > How does that make any sense? :) > > Shouldn't we rather return an error when setting a range that is > impossible, instead of the hardware deciding to scrub something > completely different (as can be seen in the example)? > A broader scrub is probably reasonable, but agreed that scrubbing narrower is 'interesting' as not scrubbing the memory requeseted. It's really annoying that neither ACPI table provides any proper discoverability. Whilst we can fix that long term, we are stuck with a clunky poke it and see interface in the meantime. Jonathan