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
