Hi Julien, > -----Original Message----- > From: Julien Grall <[email protected]> > Sent: 2021年8月19日 21:38 > To: Wei Chen <[email protected]>; [email protected]; > [email protected]; [email protected] > Cc: Bertrand Marquis <[email protected]> > Subject: Re: [XEN RFC PATCH 17/40] xen/arm: Introduce DEVICE_TREE_NUMA > Kconfig for arm64 > > Hi, > > On 11/08/2021 11:24, Wei Chen wrote: > > We need a Kconfig option to distinguish with ACPI based > > NUMA. So we introduce the new Kconfig option: > > DEVICE_TREE_NUMA in this patch for Arm64. > > > > Signed-off-by: Wei Chen <[email protected]> > > --- > > xen/arch/arm/Kconfig | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > > index ecfa6822e4..678cc98ea3 100644 > > --- a/xen/arch/arm/Kconfig > > +++ b/xen/arch/arm/Kconfig > > @@ -33,6 +33,16 @@ config ACPI > > Advanced Configuration and Power Interface (ACPI) support for Xen > is > > an alternative to device tree on ARM64. > > > > +config DEVICE_TREE_NUMA > > The name suggests that NUMA should only be enabled for Device-Tree... > But the description looks generic. > > However, I think the user should only have the choice to say whether > they want NUMA to be enabled or not. We should not give them the choice > to enable/disable the parsing for DT/ACPI. > > So we should have a generic config that will then select DT (and ACPI in > the future). >
How about we select DT_NUMA default on Arm64. And DT_NUMA select NUMA like what we have done in patch#6 in x86? And remove the description? If we make generic NUMA as a selectable option, and depends on NUMA to select DT or ACPI NUMA. It seems to be quite different from the existing logic? > > + bool "NUMA (Non-Uniform Memory Access) Support (UNSUPPORTED)" if > UNSUPPORTED > > + depends on ARM_64 > > + select NUMA > > + ---help--- > > + > > + Non-Uniform Memory Access (NUMA) is a computer memory design used > in > > + multiprocessing, where the memory access time depends on the > memory > > + location relative to the processor. > > + > > Cheers, > > -- > Julien Grall
