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

["Luck, Tony" <tony.luck@intel.com>]

> > 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.

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