Re: [RFC PATCH 3/4] xen/arm: Sanitize cpuinfo ID registers fields

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien

[…]
>> 
>> +
>> +    if ( old_reg != new_reg )
>> +        printk(XENLOG_DEBUG "SANITY DIF: %s 0x%"PRIx64" -> 0x%"PRIx64"\n",
>> +               reg_name, old_reg, new_reg);
>> +    if ( old_reg != *cur_reg )
>> +        printk(XENLOG_DEBUG "SANITY FIX: %s 0x%"PRIx64" -> 0x%"PRIx64"\n",
>> +               reg_name, old_reg, *cur_reg);
>> +
>> +    if ( taint )
>> +    {
>> +        printk(XENLOG_WARNING "SANITY CHECK: Unexpected variation in %s.\n",
>> +                reg_name);
>> +        add_taint(TAINT_CPU_OUT_OF_SPEC);
>> +    }
>> +}
>> +
>> +
>> +/*
>> + * This function should be called on secondary cores to sanitize the boot 
>> cpu
>> + * cpuinfo.
> 
> Can we renamed boot_cpu_data to system_cpuinfo (or something similar)? This 
> would make clear this is not only the features for the boot CPU?

While looking at this request, I checked a bit how boot_cpu_data and cpu_data 
overall are used:
- boot_cpu_data is only used in setup.c, by boot_cpu_features macros, in 
smpboot to retrieve the bootcpu midr, in p2m and by cpufeatures
- cpu_data[] is used in smpboot, in errata handling to test for csv2, and in 
vcpreg to access the midr

So we have a bunch of cpuinfo structures as global variables but most of them 
are not really used or did I miss something ?

So I am wondering if we should not reduce a bit the amount of global data and:
- introduce a global system_cpuinfo
- remove cpu_data[] and use a temp structure in the stack of the cpu booting
- read midr directly in vcpreg
- use boot_cpu_data in errata for csv2
- use system_cpuinfo in p2m

It could even be possible to remove boot_cpu_data and put it on the stack of 
the boot cpu and only use system_cpuinfo but I did not investigate this.

Cheers
Bertrand