[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 14/37] xen/x86: use name fw_numa to replace acpi_numa
On 23.09.2021 14:02, Wei Chen wrote: > --- a/xen/arch/x86/numa.c > +++ b/xen/arch/x86/numa.c > @@ -51,11 +51,11 @@ cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly; > nodemask_t __read_mostly node_online_map = { { [0] = 1UL } }; > > bool numa_off; > -s8 acpi_numa = 0; > +s8 fw_numa = 0; In x86 code I'd prefer this to remain "acpi_numa". If you need to access the variable from to-become-generic code, introduce an inline wrapper (possibly named numa_mode()), allowing you to do whatever you need in the DT case. It may be helpful to fold this with numa_off then, seeing e.g. ... > int srat_disabled(void) > { > - return numa_off || acpi_numa < 0; > + return numa_off || fw_numa < 0; ... this. Actually I think the underlying enumeration could even be made generic: enum numa_mode { numa_off, numa_on, numa_acpi, }; is, I believe, sufficient to express the present (numa_off,acpi_numa) tuple. In this context I'd like to point out that the two uses of acpi_numa in srat_parse_regions() and srat_detect_node() should likely be invocations of srat_disabled() instead, to also take numa_off into account. This would then be addressed effectively as a side effect by replacing open-coded uses as well as srat_disabled() by numa_mode() (or whichever name the new helper would gain). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |