Re: [PATCH 1/2] x86: during boot, anticipate identifying the boot cpu

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.08.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
> On 22/08/14 18:15, Dario Faggioli wrote:
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -59,7 +59,8 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>>  cpumask_t cpu_online_map __read_mostly;
>>  EXPORT_SYMBOL(cpu_online_map);
>>  
>> -struct cpuinfo_x86 cpu_data[NR_CPUS];
>> +struct cpuinfo_x86 cpu_data[NR_CPUS] =
>> +	{ [0 ... NR_CPUS-1] = { .phys_proc_id=-1 } };
> 
> This moves a huge chunk of data from .bss to .data.  Can it not be fixed
> by enumerating topology on APs before setting scheduling up?

Yeah, I was intending to ask the same thing. Just set .phys_proc_id
to -1 early during CPU bringup.

>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -213,8 +213,10 @@ extern void detect_extended_topology(struct cpuinfo_x86 *c);
>>  
>>  extern void detect_ht(struct cpuinfo_x86 *c);
>>  
>> -#define cpu_to_core(_cpu)   (cpu_data[_cpu].cpu_core_id)
>> -#define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id)
>> +#define cpu_to_core(_cpu)    (cpu_data[_cpu].cpu_core_id)
>> +#define cpu_to_socket(_cpu)  (cpu_data[_cpu].phys_proc_id)
>> +#define boot_cpu_to_core()   (boot_cpu_data.phys_core_id)
>> +#define boot_cpu_to_socket() (boot_cpu_data.phys_proc_id)
> 
> This change is pointless.  Anything explicitly referencing the bsp
> should just use boot_cpu_data directly, rather than obscuring the IDs
> behind macros like this.

If the purpose is to use these in arch-independent code, I think
the "obscuring" actually makes sense.

Jan