On Thu, Aug 21, 2025 at 04:16:02PM +0000, Luck, Tony wrote:

quoted

quoted

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.