On 15.04.2024 16:17, Roger Pau Monne wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -643,7 +643,7 @@ static void __init print_details(enum ind_thunk thunk)
> opt_eager_fpu ? " EAGER_FPU" : "",
> opt_verw_hvm ? " VERW" : "",
> boot_cpu_has(X86_FEATURE_IBPB_ENTRY_HVM) ? " IBPB-entry" : "",
> - cpu_has_bhb_seq ? " BHB-entry" :
> "");
> + opt_bhb_entry_hvm ? " BHB-entry" :
> "");
>
> #endif
> #ifdef CONFIG_PV
> @@ -658,7 +658,7 @@ static void __init print_details(enum ind_thunk thunk)
> opt_eager_fpu ? " EAGER_FPU" : "",
> opt_verw_pv ? " VERW" : "",
> boot_cpu_has(X86_FEATURE_IBPB_ENTRY_PV) ? " IBPB-entry" : "",
> - cpu_has_bhb_seq ? " BHB-entry" :
> "");
> + opt_bhb_entry_pv ? " BHB-entry" :
> "");
>
> printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
> opt_xpti_hwdom ? "enabled" : "disabled",
For one the surrounding if() conditions need similar adjustment.
But then I wonder whether the further uses of cpu_has_bhb_seq don't
need switching, too (when determining whether to force
X86_SPEC_NO_LFENCE_ENTRY_*). At which point the question is why
cpu_has_bhb_seq exists in the first place: It in particular does not
affect the default calculation of opt_bhb_entry_*, afaics.
Jan
