Re: [PATCH] arm64: Remove arm64_dma32_phys_limit and its uses

[Nicolas Saenz Julienne <nsaenzjulienne@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --]

On Mon, 2021-01-11 at 16:57 +0000, Catalin Marinas wrote:
> On Thu, Jan 07, 2021 at 06:40:32PM +0000, Catalin Marinas wrote:
> > With the introduction of a dynamic ZONE_DMA range based on DT or IORT
> > information, there's no need for CMA allocations from the wider
> > ZONE_DMA32 since on most platforms ZONE_DMA will cover the 32-bit
> > addressable range. Remove the arm64_dma32_phys_limit and set
> > arm64_dma_phys_limit to cover the smallest DMA range required on the
> > platform. CMA allocation and crashkernel reservation now goes in
> > the dynamically sized ZONE_DMA.
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > Cc: Chen Zhou <chenzhou10@huawei.com>
> > ---
> > 
> > This patch goes on top of the ARCH_LOW_ADDRESS_LIMIT fix from Nicolas,
> > already in the arm64 for-next/fixes which fixes a 5.5 issue with
> > !CONFIG_ZONE_DMA. The changes here depend on the patches in 5.11-rc1.
> > While they look mostly like clean-ups, they still fix a potential issue
> > with !CONFIG_ZONE_DMA32 configurations where arm64_dma32_phys_limit
> > would be equal to PHYS_MASK but we still have a limited ZONE_DMA. In
> > addition, it now allows proper CMA and crashkernel reservations for
> > RPi4.
> [...]
> > @@ -394,16 +399,9 @@ void __init arm64_memblock_init(void)
> >  
> > 
> >  	early_init_fdt_scan_reserved_mem();
> >  
> > 
> > -	if (IS_ENABLED(CONFIG_ZONE_DMA32))
> > -		arm64_dma32_phys_limit = max_zone_phys(32);
> > -	else
> > -		arm64_dma32_phys_limit = PHYS_MASK + 1;
> > -
> >  	reserve_elfcorehdr();
> >  
> > 
> >  	high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > -
> > -	dma_contiguous_reserve(arm64_dma32_phys_limit);
> >  }
> >  
> > 
> >  void __init bootmem_init(void)
> > @@ -438,6 +436,11 @@ void __init bootmem_init(void)
> >  	sparse_init();
> >  	zone_sizes_init(min, max);
> >  
> > 
> > +	/*
> > +	 * Reserve the CMA area after arm64_dma_phys_limit was initialised.
> > +	 */
> > +	dma_contiguous_reserve(arm64_dma_phys_limit);
> 
> Prior to this patch, disabling CONFIG_ZONE_DMA32 leads to CMA allocation
> from the whole RAM as arm64_dma32_phys_limit becomes PHYS_MASK+1. With
> this patch (which I plan to merge in 5.11-rc4), we limit the CMA
> allocation to the 32-bit addressable RAM (if any) even if we don't
> describe anything in DT or IORT since ZONE_DMA is capped at 32-bit. We
> could relax this so that ZONE_DMA can be expanded beyond 32-bit with
> ZONE_DMA32 disabled and no DT/IORT information. Is there a real use-case
> for such configuration?

AFAIK there is a good amount of PCIe cards that depend on 32-bit addressing. So
expanding ZONE_DMA beyond 32-bit would potentially break those. That said I
don't have any concrete example of people using this.

> We might as well make ZONE_DMA depend on ZONE_DMA32 (though given the EXPERT
> dependency, people should know what they are doing...).

I guess in the long run it'll make things easier to mantain, so it has its
value.

> An alternative would be to change max_zone_phys() to avoid the U32_MAX
> cap if ZONE_DMA32 is disabled but I don't think it's worth as I don't
> see much point in a kernel config with ZONE_DMA enabled and ZONE_DMA32
> disabled.

Agree, it seems a pointless configuration. On top of that, AFAIK, there isn't
any drawback to having a zero sized ZONE_DMA32.

Regards,
Nicolas


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel