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.
