Re: [PATCH] riscv/mm: use physical alignment for vmemmap_start_pfn

[Kiryl Shutsemau]

On Mon, Jul 20, 2026 at 05:20:16PM +0800, Muchun Song wrote:
> 
> 
> > On Jul 16, 2026, at 19:53, Jiakai Xu <xujiakai2025@xxxxxxxxxxx> wrote:
> > 
> > RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
> > VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the
> > physical-address domain.
> > 
> > Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
> > attempted to account for the maximal folio alignment by feeding
> > MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However,
> > MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
> > whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.
> > 
> > The mask-based compound_info encoding requires pfn_to_page(0) to be
> > naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa
> > ("mm/sparse: check memmap alignment for compound_info_has_mask()")
> > added a check for that requirement and exposed the unit mismatch on
> > systems such as QEMU virt, where the DRAM base is not aligned to
> > MAX_FOLIO_NR_PAGES * PAGE_SIZE.
> > 
> > Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
> > before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing
> > round_down() logic while making the resulting vmemmap base satisfy the
> > mask-alignment requirement.
> > 
> > Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
> > Signed-off-by: Jiakai Xu <xujiakai2025@xxxxxxxxxxx>
> > Assisted-by: YuanSheng:DeepSeek-V4-Flash
> 
> I've always wondered why RISC-V uses a complex logic to calculate the
> mapping relationship between vmemmap and PFN. We could easily follow the
> x86 approach to make it much simpler.

I am not an expert in riscv mm, but the git history suggests it is
deliberate. See a11dd49dcb93 ("riscv: Sparse-Memory/vmemmap out-of-bounds
fix") and f754f27e98f8 ("riscv: mm: Fix the out of bound issue of vmemmap
address").

As far as I can tell, the constraint is the size of the vmemmap window:

      #define VMEMMAP_SHIFT \
              (VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT)

On sv39 that is a 4GiB window, enough struct pages for a 256GiB span of
physical memory. The vmemmap_start_pfn bias anchors the window at the
DRAM base, so any base works as long as the span fits. Base vmemmap at
pfn 0 and the window becomes absolute: physical memory above 256GiB is
not representable and struct page addresses run past VMEMMAP_END into
vmalloc space. Unlike x86-64, sv39 doesn't have the virtual address
space to size the window for the whole 56-bit physical space.

It boots fine on QEMU virt because DRAM sits at 2GiB there.

Whether any real sv39 platform places memory above 256GiB is a question
for the riscv folks. But if the answer is yes, the simplification is not
available on sv39.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov