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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

> The next step (not upstream yet) is to regenerate the Host and Guest
> policies.  I recently fixed a bug in XenServer's testing and noticed
> that the underlying logic had bit-rotted quite a bit, hence this series.
> 
> The purpose is to be able to activate new features added by a late
> microcode load, such as new speculative defences, or simply provide new
> FOO_NO bits.

Yes, that's a good goal.

Jan