Re: [PATCH v11 1/3] mm: Add support to retrieve physical address range of memory from the node ID

[Mike Rapoport <rppt@kernel.org>]

On Thu, Aug 21, 2025 at 04:16:02PM +0000, Luck, Tony wrote:
> > > I believe that's because on x86 the node 0 is really scrambled because of
> > > e820/efi reservations that never make it to memblock.
> >
> > Fun question of whether we should take any notice of those.
> > Would depend on whether anyone's scrub firmware gets confused if we scrub
> > them and they aren't backed by memory.  If they are we can rely on system
> > constraints refusing to scrub that stuff at an 'unsafe' level and if we
> > set it higher than it otherwise would be only possibility is we see earlier
> > error detections in those and have to deal with them.
> 
> Yes. On x86 the physical memory map below 4GB is a bunch of address
> ranges with varying properties:
> 
> 1) There's the "low" MMIO region (often 2G to very nearly 4G) where 32-bit
>    PCI devices have device BAR ranges mapped. Some of this isn't memory
>    at all. It's device registers that may have side effects when read. I don't think
>    the x86 patrol scrubbers can access this at all.
> 2) There's EFI allocated memory that is accessible to the OS (e.g. ACPI tables)
> 3) There's BIOS protected memory for use by SMI that the OS can't access at all
> 4) There are ranges listed in E820 or efi_memory_map that are usable by OS.

There is a slight problem here with getting the first contiguous range from
a node to seed the scrubber.
If we use PXM, the range for node 0 will usually cover the entire node
including types 1 and 3. And if we take it from memblock, it does not include
type 2, or anything reserved in e820/efi.
 
> What is the use case for OS control of the patrol scrubbers?
> 
> While you might want to specifically scrub some range to make sure there
> are no lurking problems before allocating to some important process/guest,
> I'd expect that you'd want to make sure that types 2 & 3 listed above still
> get a periodic scan to clean up single bit errors.
> 
> -Tony

-- 
Sincerely yours,
Mike.