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: 16 October 2025 11:31
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: 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 Mon, Oct 06, 2025 at 10:37:39AM +0000, Shiju Jose wrote:
>> 1.Scrub rate
>> 1.1. Scrub rate is common across the NUMA node domains.
>> 1.2. Common min scrub rate is max of min scrub rates across nodes.
>> 1.3. Common max scrub rate is min of max scrub rates across nodes.
>
>And you need scrub rate to be per node because...?
>
>Why can't it be a system-wide scrub rate?

ACPI spec defined RAS2 interface for scrub and scrub parameters per node .
Thus to make compatible to the spec,  kernel and firmware implementations for
RAS2 scrubbing are per node. 
For the design and prototyping your request for "start a scrub on the whole system", 
we are trying make sysfs scrub control system-wide while keeping underlying RAS2
scrubbing per node. Then these open questions arise, such as need for the 
system-wide common scrub rate across all nodes,  for the demand scrubbing should
the kernel send scrub request to only on the corresponding node or to all the nodes etc.
>
>If the use case appears which needs per-node scrub rate, then you design it this
>way.

From the ACPI spec RAS2 scrub interface perspective,  needs per-node scrub rate and other
scrub parameters. One of the use case for demand/background scrubbing in a specific node
in which frequent corrected memory errors reported to the user space and CE count exceeds the
threshold.

May be Daniel can provide more inputs for this question about use cases?
 
If you agree to keep per-node scrub rate and thus per-node scrub control in the sysfs,
then I will continue to use the original design in v12? Otherwise will try to use the new design
with common system-wide scrub control in the sysfs and underlying RAS2 scrubbing 
implementation per node.

>
>Or you already have a valid use case for it which dictates this design?
>
>> 1.4. Scrub rate allowed to change only if NO demand and patrol
>>    scrubbing is in progress
>
>Right.
>
>> 2. Demand scrubbing and Background (patrol) scrubbing 2.1. Background
>> scrubbing request enables BG scrubbing
>>      on all NUMA nodes.
>
>Right.
>
>> 2.2. For, demand scrubbing request 2 options are identified,
>>      with (b) tried. Please suggest the right approach?
>> a) Enable demand scrubbing on all NUMA nodes, hope for
>>      the 'Requested Address Range(INPUT)' field, can use
>>      address set to scrub and PAGE_SIZE(or similar) for all the
>>      nodes.
>
>Why do you need an address range? Why not start scrubbing and have it be fire-
>and-forget?
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.

>
>> b) Enable demand scrubbing on a NUMA node for which
>>      the requested address to scrub is within the PA range of
>>      that node.
>>
>> 2.3. Demand scrubbing is not allowed when background scrubbing
>>      is in progress.
>>
>> 2.4. If 2.2. (b) is chosen, should kernel allow BG
>>       scrubbing on rest of the nodes, when demand scrubbing on
>>       some node/s is in progress?
>
>It seems like all scrubbing should be mutually-exclusive... or is there a point in
>scrubbing in parallel...?

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. 
>
>> 2.5 The status of the BG scrubbing exposed to the user space
>>     in 'enable_background' sysfs attribute.
>>
>> 2.6 The status of the demand scrubbing exposed to the
>>        user space in 'addr' sysfs attribute. However when the
>>        demand scrubbing is on multiple/all nodes are in progress,
>>        which demand scrubbing status and address in 'addr' sysfs attribute
>>        as status should be exposed to the user space?
>> a) May be the status of the first detected node with demand scrubbing
>>      is in progress?
>> b) Does not show the status at all, just fail the request if the
>>     demand scrubbing is already in progress on a node/all nodes?
>> c)  Any other suggestion?
>
>First we need a proper granularity defined and then everything will revolve
>around it: should it be system-wide, per-node, does it need to have an address
>range or can it be started and no need for any further user interaction and so on
>and so on...
Sure.
>

Thanks,
Shiju

>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette