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
