RE: [PATCH v12 1/2] ACPI:RAS2: Add ACPI RAS2 driver

[Shiju Jose <shiju.jose@huawei.com>]

>-----Original Message-----
>From: Borislav Petkov <bp@alien8.de>
>Sent: 03 November 2025 13:19
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: Daniel Ferguson <danielf@os.amperecomputing.com>; Jonathan Cameron
><jonathan.cameron@huawei.com>; rafael@kernel.org; akpm@linux-
>foundation.org; rppt@kernel.org; dferguson@amperecomputing.com; linux-
>edac@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux-
>doc@vger.kernel.org; tony.luck@intel.com; lenb@kernel.org;
>Yazen.Ghannam@amd.com; mchehab@kernel.org; Linuxarm
><linuxarm@huawei.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; wbs@os.amperecomputing.com;
>nifan.cxl@gmail.com; tanxiaofei <tanxiaofei@huawei.com>; Zengtao (B)
><prime.zeng@hisilicon.com>; Roberto Sassu <roberto.sassu@huawei.com>;
>kangkang.shen@futurewei.com; wanghuiqiang <wanghuiqiang@huawei.com>
>Subject: Re: [PATCH v12 1/2] ACPI:RAS2: Add ACPI RAS2 driver
>
>On Fri, Oct 17, 2025 at 12:54:36PM +0000, Shiju Jose wrote:
[...]
>
>> This is for demand scrubbing feature/use case where a specific address
>> range to scrub and OS must set the mandatory  spec defined  RAS2 table
>> field 'Requested Address Range(INPUT)' while requesting the demand
>> scrubbing in a node. Hope the firmware can ignore the request if the
>> requested address range to scrub is irrelevant for a node, because in
>> this approach we have common sysfs scrub control and kernel is
>> requesting demand scrubbing system-wide across all nodes.
>>
>> If this approach is not correct, can we use (b) as below? providing we
>> need to get PA range for the nodes in the RAS2 driver  using the
>> functions (start_pfn = node_start_pfn(nid) and size_pfn =
>> node_spanned_pages(nid);) as implemented in v12 and discussed earlier in this
>thread.
>>
>
>I'm wondering how useful that address range scrubbing would be and whether it
>is worth the effort... I guess the goal here is something along those lines:
>"oh, you just had an error at address X, so let's scrub [ A ... X ... B ] with A and B
>having, hm, dunno, sufficient values to contain X and perhaps cover sufficient
>range to catch error locality or whatnot.
>
>But you'd need to do this only when you have a fat memory node and where you
>start scrubbing at the beginning of the node range and then you'd have to wait
>for a relatively long time to reach the PA X at fault...
>
>But I have a better idea: how about you start at X - y, i.e., at an address a bit
>smaller than the last reported one and then continue from there on, reach the
>*end* of the node and then wraparound to the beginning until you reach X
>again?
>
>This way you don't need to supply any range and you are still "on time" when
>reacting to the error with scrubbing...
>
>Hmmm?
Thanks Borislav for the valuable suggestion and it make sense. Since presently we are
not sure how reaching the end of the node work on individual platforms,  can we do
this as an optimization in the next stage? and 
Can we start with basic demand scrubbing without address range control in sysfs,
but with user space set only scrub rate and enable_demand, kernel set the
node's addr range as Requested Address Range to start the demand scrubbing on
entire node, as you suggested?
>
>> Sure. Then background scrubbing will not be allowed if demand
>> scrubbing is in progress in a node, if the system-wide scrub control in sysfs is
>chosen.
>
>So can the kernel interrupt background scrubbing on some node? Because then it
>is easy:
RAS2 STOP_PATROL_SCRUBBER  command allows interrupting background scrubbing.  
>
>You interrupt background scrubbing whenever needed with on-demand
>scrubbing on that particular node...
>
Sure. Will do.
>It looks like it is starting to crystallize...
>

Thanks,
Shiju