linux-kernel - RE: [PATCH] x86/numa: Add Devicetree support

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]

Message-ID: <BYAPR21MB16885DEA2F3248B137EACC22D70BA@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Wed, 2 Aug 2023 18:49:03 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Saurabh Sengar <ssengar@...ux.microsoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86/numa: Add Devicetree support

From: Saurabh Sengar <ssengar@...ux.microsoft.com> Sent: Tuesday, June 27, 2023 12:28 AM
> 
> Hyper-V has usecases where it need to fetch NUMA information from
> Devicetree. Currently, it is not possible to extract the NUMA
> information from Devicetree for x86 arch.
> 
> Add support for Devicetree in the x86_numa_init function, allowing
> the retrieval of NUMA node information from the Devicetree.
> 
> Additionally, relocate the x86_dtb_init function before initmem_init
> to ensure the Devicetree initialization prior to its utilization in
> x86_numa_init.
> 
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> ---
>  arch/x86/Kconfig        | 1 +
>  arch/x86/kernel/setup.c | 2 +-
>  arch/x86/mm/numa.c      | 3 +++
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c531b16ee0bf..a2ada193b2d8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1567,6 +1567,7 @@ config NUMA
>  	depends on X86_64 || (X86_32 && HIGHMEM64G && X86_BIGSMP)
>  	default y if X86_BIGSMP
>  	select USE_PERCPU_NUMA_NODE_ID
> +	select OF_NUMA if OF
>  	help
>  	  Enable NUMA (Non-Uniform Memory Access) support.
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index fd975a4a5200..940c92a6a5e9 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1220,6 +1220,7 @@ void __init setup_arch(char **cmdline_p)
> 
>  	early_acpi_boot_init();
> 
> +	x86_dtb_init();
>  	initmem_init();
>  	dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT);
> 
> @@ -1261,7 +1262,6 @@ void __init setup_arch(char **cmdline_p)
>  	 * Read APIC and some other early information from ACPI tables.
>  	 */
>  	acpi_boot_init();
> -	x86_dtb_init();
> 
>  	/*
>  	 * get boot-time SMP configuration:
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 2aadb2019b4f..a6d3d331fda2 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -11,6 +11,7 @@
>  #include <linux/nodemask.h>
>  #include <linux/sched.h>
>  #include <linux/topology.h>
> +#include <linux/of.h>
> 
>  #include <asm/e820/api.h>
>  #include <asm/proto.h>
> @@ -733,6 +734,8 @@ void __init x86_numa_init(void)
>  		if (!numa_init(amd_numa_init))
>  			return;
>  #endif
> +		if (acpi_disabled && !numa_init(of_numa_init))
> +			return;
>  	}
> 
>  	numa_init(dummy_numa_init);
> --
> 2.34.1

This looks good to me.  I've looked and don't see any
obvious issues in moving x86_dtb_init() earlier in
setup_arch().  But I also know the setup ordering can
be very tricky to get working correctly with a wide
range of platforms, and I don't have that expertise.
But with those caveats,

Reviewed-by: Michael Kelley <mikelley@...rosoft.com>