On 12.03.2024 16:29, Krystian Hebel wrote: > On 7.02.2024 17:41, Jan Beulich wrote: >> On 02.02.2024 19:11, Julien Grall wrote: >>> On 14/11/2023 17:50, Krystian Hebel wrote: >>>> --- a/xen/arch/x86/numa.c >>>> +++ b/xen/arch/x86/numa.c >>>> @@ -54,14 +54,13 @@ bool __init arch_numa_unavailable(void) >>>> /* >>>> * Setup early cpu_to_node. >>>> * >>>> - * Populate cpu_to_node[] only if x86_cpu_to_apicid[], >>>> - * and apicid_to_node[] tables have valid entries for a CPU. >>>> - * This means we skip cpu_to_node[] initialisation for NUMA >>>> - * emulation and faking node case (when running a kernel compiled >>>> - * for NUMA on a non NUMA box), which is OK as cpu_to_node[] >>>> - * is already initialized in a round robin manner at numa_init_array, >>>> - * prior to this call, and this initialization is good enough >>>> - * for the fake NUMA cases. >>>> + * Populate cpu_to_node[] only if cpu_data[], and apicid_to_node[] >> You mean cpu_physical_id() here, and then this change wants doing when >> switching to that, imo. > You mean s/cpu_data[]/cpu_physical_id()/ or something else?
Well, in general terms - whatever the function in fact accesses. That's, if I reconstruct it from patch 2, as you say then. Jan
