Re: [RFC] Kernel Support of Memory Error Detection.

[Jiaqi Yan <jiaqiyan@google.com>]

On Tue, Nov 8, 2022 at 9:04 PM HORIGUCHI NAOYA(堀口　直也)
<naoya.horiguchi@nec.com> wrote:
>
> On Tue, Nov 08, 2022 at 04:17:06PM +0000, Luck, Tony wrote:
> > > If it is feasible in future that hardware vendors can make patrol
> > > scrubber programmable, we can even direct the scanning to patrol
> > > scrubber.
> >
> > There was an attempt to create an ACPI interface for this. I don't know if it made
> > it into the standard.
>
> I briefly checked the latest ACPI spec, and it seems that some interfaces
> to control (h/w based) patrol scrubbing are defined.
>
> https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#acpi-ras-feature-table-rasf

Thanks for the link!
Once the "how to scan" part reaches consensus, we will make sure the
concrete API/implementation is compatible/able to direct scan to
patrol scrubber.

>
> > I didn't do anything with it for Linux because the interface was
> > quite complex.
> >
> > From a h/w perspective it might always be complex. Consecutive system physical
> > addresses are generally interleaved across multiple memory controllers, channels,
> > DIMMs and ranks. While patrol scrubbing may be done by each memory controller
> > at the channel level.
> >
> > So a simple request to scan a few megabytes of system physical address would
> > require address translation to figure out the channel addresses on each of the
> > memory controllers and programming each to scan the pieces they contribute to
> > the target range.
>
> I expect that the physical address visible to the kernel is transparently
> translated to the real address in which DIMM in which channel.
>
> - Naoya Horiguchi