Re: [PATCH 1/3] x86/amd: Use setup_force_cpu_cap() for BTC_NO

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/11/2025 3:25 pm, Jan Beulich wrote:
> On 26.11.2025 16:12, Andrew Cooper wrote:
>> On 26/11/2025 2:19 pm, Jan Beulich wrote:
>>> On 26.11.2025 14:22, Andrew Cooper wrote:
>>>> When re-scanning features,
>>> What exactly do you mean with this, outside of XenServer (i.e. upstream)? 
>>> The
>>> only thing I can think of is recheck_cpu_features(), which calls 
>>> identify_cpu()
>>> and hence init_amd(). Thus ...
>>>
>>>> forced caps are taken into account but unforced
>>>> such as this are not.  This causes BTC_NO to go missing, and for the 
>>>> system to
>>>> appear to have lost features.
>>> ... I don't really follow where features might be lost.
>> Well - it's a feature that we started upstreaming and I still hope to
>> finish in some copious free time.
>>
>> Already upstream, we rescan the Raw CPU policy after microcode load. 
>> That has had fixes such as dis-engaging CPUID Masking/Overriding so the
>> Raw policy comes out accurate.
> Yet that doesn't take forced features into account afaics. So at the very
> least this needs to come with a description which more accurately describes
> what (if anything) is actually being fixed / altered upstream.

I don't know what more you want me to say.  It's not a problem per say
in upstream, but it does come about because BTC_NO is handled
inconsistently to the other FOO_NO bits.

recheck_cpu_features() papers over the issue by re-invoking
identify_cpu().  It's necessary for S3 resume because all of
init_$VENDOR() really is needed, but it looks bogus in
smp_store_cpu_info() because it's repeating work done immediately prior
in start_secondary().

~Andrew