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.

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.

~Andrew

Reply via email to