Re: [PATCH] x86: always store APIC ID of CPU

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/06/14 12:30, Jan Beulich wrote:
>>>> On 26.06.14 at 13:02, <andrew.cooper3@citrix.com> wrote:
>> On 26/06/14 11:11, Jan Beulich wrote:
>>> +/*
>>> + * cpuid returns the value latched in the HW at reset, not the APIC ID
>>> + * register's value.  For any box whose BIOS changes APIC IDs, like
>>> + * clustered APIC systems, we must use hard_smp_processor_id.
>>> + *
>>> + * See Intel's IA-32 SW Dev's Manual Vol2 under CPUID.
>>> + */
>>> +static inline u32 phys_pkg_id(u32 cpuid_apic, int index_msb)
>> What is the point of the cpuid_apic parameter?  It is unused.
>>
>> index_msb should probably be unsigned as it is used to shift with.
> For both of these - yes, I agree, but no, I don't want to change
> this here (I'm just moving the function up after all). The history of
> this is a bit difficult to interpret: Before in change in 2006 some
> variants of this function used both inputs, but some didn't. I
> suppose Keir didn't want to risk breaking clustered APIC systems,
> albeit as far as I looked only Summit systems were actually ignoring
> the passed in APIC ID, and we're not supporting these anymore.
>
> As to shift counts, I don't think it really matters whether they're
> signed or unsigned, as anything outside the range [0,bitwidth-1]
> produce undefined operations anyway.
>
> Jan
>

Fair enough.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>