linux-kernel - Re: [PATCH] ARM64: Setup DMA32 zone size by bootargs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Aug 2020 16:39:39 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Phil Chang <phil.chang@...iatek.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Mark Rutland <mark.rutland@....com>,
        Alix Wu <alix.wu@...iatek.com>, linux-doc@...r.kernel.org,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Steve Capper <steve.capper@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        YJ Chiang <yj.chiang@...iatek.com>,
        Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH] ARM64: Setup DMA32 zone size by bootargs

On 2020-08-03 15:26, Phil Chang wrote:
> this patch allowing the arm64 DMA zone be configurable.
> 
> Signed-off-by: Alix Wu <alix.wu@...iatek.com>
> Signed-off-by: YJ Chiang <yj.chiang@...iatek.com>
> Signed-off-by: Phil Chang <phil.chang@...iatek.com>
> ---
> Hi
> 
> For some devices, the main memory split into 2 part due to the memory architecture,
> the efficient and less inefficient part.
> One of the use case is fine-tune the dma32 size to contain all the
> efficient part of memory block on this kind of architecture,
> but in general, the DMA32 zone size is hardcode to 4G.

The sole point of ZONE_DMA32 is to contain all the 32-bit addressable 
memory which is not covered by ZONE_DMA. As such the only possible thing 
that could be configured is the size of ZONE_DMA (if present), and this 
patch makes no sense.

If you want to describe NUMA characteristics, use NUMA properties. 
Giving users freedom to break fundamental assumptions of the DMA layer 
by arbitrarily changing the meaning of "32-bit" is not an appropriate 
solution.

Robin.

>   .../admin-guide/kernel-parameters.txt         |  3 ++
>   arch/arm64/include/asm/memory.h               |  2 ++
>   arch/arm64/mm/init.c                          | 33 +++++++++++++++++--
>   3 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index fb95fad81c79..441ad3cb8ee8 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -956,6 +956,9 @@
>   			The filter can be disabled or changed to another
>   			driver later using sysfs.
>   
> +	dma32_zone=nn	[KMG] [KNL,BOOT]
> +			Forces the DMA32 zone size of <nn> in mb, arm64 only.
> +
>   	driver_async_probe=  [KNL]
>   			List of driver names to be probed asynchronously.
>   			Format: <driver_name1>,<driver_name2>...
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index a1871bb32bb1..377f2252618a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -174,6 +174,8 @@ extern u64			kimage_vaddr;
>   /* the offset between the kernel virtual and physical mappings */
>   extern u64			kimage_voffset;
>   
> +extern phys_addr_t		arm_dma_zone_size;
> +
>   static inline unsigned long kaslr_offset(void)
>   {
>   	return kimage_vaddr - KIMAGE_VADDR;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 1e93cfc7c47a..642ab323392c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -60,6 +60,9 @@ EXPORT_SYMBOL(physvirt_offset);
>   struct page *vmemmap __ro_after_init;
>   EXPORT_SYMBOL(vmemmap);
>   
> +phys_addr_t arm_dma_zone_size __ro_after_init;
> +EXPORT_SYMBOL(arm_dma_zone_size);
> +
>   /*
>    * We create both ZONE_DMA and ZONE_DMA32. ZONE_DMA covers the first 1G of
>    * memory as some devices, namely the Raspberry Pi 4, have peripherals with
> @@ -242,6 +245,25 @@ static int __init early_mem(char *p)
>   }
>   early_param("mem", early_mem);
>   
> +/*
> + * Setup the dma32 zone size
> + */
> +static int __init setup_dma32_zone(char *p)
> +{
> +	if (!p)
> +		return -EINVAL;
> +
> +	if (kstrtoull(p, 0, &arm_dma_zone_size))
> +		return -EINVAL;
> +
> +	arm_dma_zone_size *= SZ_1M;
> +	pr_notice("Setup dma32 zone size to %llu Mb\n", arm_dma_zone_size);
> +
> +	return 0;
> +}
> +
> +early_param("dma32_zone", setup_dma32_zone);
> +
>   static int __init early_init_dt_scan_usablemem(unsigned long node,
>   		const char *uname, int depth, void *data)
>   {
> @@ -392,10 +414,15 @@ void __init arm64_memblock_init(void)
>   		arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
>   	}
>   
> -	if (IS_ENABLED(CONFIG_ZONE_DMA32))
> -		arm64_dma32_phys_limit = max_zone_phys(32);
> -	else
> +	if (IS_ENABLED(CONFIG_ZONE_DMA32)) {
> +		if (arm_dma_zone_size)
> +			arm64_dma32_phys_limit = arm_dma_zone_size +
> +						memblock_start_of_DRAM();
> +		else
> +			arm64_dma32_phys_limit = max_zone_phys(32);
> +	} else {
>   		arm64_dma32_phys_limit = PHYS_MASK + 1;
> +	}
>   
>   	reserve_crashkernel();
>   
>