Re: [PATCH v2 1/2] x86/Intel: Sapphire Rapids Xeons also support PPIN

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.01.2022 00:01, Andrew Cooper wrote:
> On 20/01/2022 14:16, Jan Beulich wrote:
>> This is as per Linux commit a331f5fdd36d ("x86/mce: Add Xeon Sapphire
>> Rapids to list of CPUs that support PPIN") just in case a subsequent
>> change making use of the respective new CPUID bit doesn't cover this
>> model.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Sadly,
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=e464121f2d40eabc7d11823fb26db807ce945df4
> 
> 
> IceLake-D too.
> 
> Preferably with this fixed, Acked-by: Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx> (to save a trivial repost),

Sure, added. And thanks.

> but ...
> 
>> ---
>> It is unclear to me whether this change is actually made obsolete by the
>> subsequent one adding support for the respective new CPUID bit.
> 
> ... Sapphire Rapids doesn't enumerate PPIN.  Hopefully Granite Rapids
> will, but everything SPR and older will have to rely on model checks only.

At least in theory I suppose they could address this by as simple as
a microcode update?

>> It also continues to be unclear for which CPU models, if any, the
>> PPIN_CAP bit in PLATFORM_INFO could be used in favor of a model check.
> 
> Presumably none, because you need the same set of model checks to
> interpret the PPIN bit in PLATFORM_INFO.  It does beg the question what
> the point of the bit is...

Well, if the bit never had a different meaning, then a model check
wouldn't be necessary. Just like e.g. probe_cpuid_faulting() doesn't
have one.

Jan