Re: [PATCH] mm: ignore nomap memory during mirror init

[Ard Biesheuvel <ardb@kernel.org>]

On Sun, 20 Jul 2025 at 22:38, Mike Rapoport <rppt@kernel.org> wrote:
>
...
>
> > w/o this patch
> > [root@localhost ~]# lsmem --output-all
> > RANGE                                  SIZE  STATE REMOVABLE         BLOCK NODE   ZONES
> > 0x0000084000000000-0x00000847ffffffff   32G online       yes   67584-67839    0 Movable
> > 0x0000085000000000-0x0000085fffffffff   64G online       yes   68096-68607    0 Movable
> >
> > w/ this patch
> > [root@localhost ~]# lsmem --output-all
> > RANGE                                  SIZE  STATE REMOVABLE         BLOCK NODE   ZONES
> > 0x0000084000000000-0x00000847ffffffff   32G online       yes   8448-8479    0  Normal
> > 0x0000085000000000-0x0000085fffffffff   64G online       yes   8512-8575    0 Movable
>
> As I see the problem, you have a problematic firmware that fails to report
> memory as mirrored because it reserved for firmware own use. This causes
> for non-mirrored memory to appear before mirrored memory. And this breaks
> an assumption in find_zone_movable_pfns_for_nodes() that mirrored memory
> always has lower addresses than non-mirrored memory and you end up wiht
> having all the memory in movable zone.
>

That assumption seems highly problematic to me on non-x86
architectures: why should mirrored (or 'more reliable' in EFI speak)
memory always appear before ordinary memory in the physical memory
map?

> So to workaround this firmware issue you propose a hack that would skip
> NOMAP regions while calculating zone_movable_pfn because your particular
> firmware reports the reserved mirrored memory as NOMAP.
>

NOMAP is a Linux construct - the particular firmware reports a
'reserved' memory region, but other more widely used memory types such
as EfiRuntimeServicesCode or *Data would result in an omitted region
as well, and can appear anywhere in the physical memory map. There is
no requirement for the firmware to do anything here wrt the
MORE_RELIABLE attribute even though such regions may be carved out of
a block of memory that is reported as such to the OS.

So I agree with Wupeng Ma that there is an issue here: reporting it as
mirrored even though it is reserved should not be needed to prevent
the kernel from mishandling it.