Re: [PATCH v3] riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB

On Mon, Jul 27, 2026 at 01:08:44AM -0700, Troy Mitchell wrote:
> On RISC-V platforms where the entire physical memory (DRAM) resides
> above the 32-bit address space (i.e., above dma32_phys_limit), the
> current SWIOTLB initialization logic fails.
> 
> This patch addresses two interconnected issues on such platforms:
> 
> 1. Incorrect 32-bit DMA bounce assumption:
> The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes
> that a 32-bit DMA bounce buffer is required simply because the maximum
> PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
> no memory exists below the limit to satisfy this allocation. Fix
> this by adding a check to ensure `memblock_start_of_DRAM()` is actually
> below the 32-bit limit before enforcing 32-bit SWIOTLB.
> 
> 2. kmalloc() bounce buffer allocation failure on non-coherent systems:
> For non-coherent DMA, kmalloc() buffers whose sizes are not
> cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
> is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
> allocating from low memory, which fails completely when DRAM only exists
> in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
> is permitted to allocate this bounce buffer from high memory.
> 
> With this patch, systems with non-coherent DMA and DRAM entirely above
> 4GB can successfully map the software IO TLB in high memory and boot
> normally.
> 
> Tested-by: Anirudh Srinivasan <[email protected]>
> Signed-off-by: Troy Mitchell <[email protected]>
> ---
> Changes in v3:
> - clarify when kmalloc() buffers require bouncing for non-coherent DMA
> - Link to v2: https://patch.msgid.link/[email protected]
> 
> Changes in v2:
> - add Anirudh's TB tag
> - Link to v1: https://lore.kernel.org/r/[email protected]

Maybe fixes tag should be added like this?

Fixes: dcb2743d1e70 ("riscv: mm: still create swiotlb buffer for kmalloc() bouncing if required")

Aside from that, LGTM and resolves the issue for Linux running on the
X280 clusters in the Tenstorrent Blackhole.

Reviewed-by: Drew Fustini <[email protected]>

Thanks,
Drew