On 18.04.2024 17:52, Roger Pau Monne wrote:
> It's currently too restrictive by just checking whether there's a BHB clearing
> sequence selected. It should instead check whether BHB clearing is used on
> entry from PV or HVM specifically.
>
> Switch to use opt_bhb_entry_{pv,hvm} instead, and then remove cpu_has_bhb_seq
> since it no longer has any users.
>
> Reported-by: Jan Beulich <jbeul...@suse.com>
> Fixes: 954c983abcee ('x86/spec-ctrl: Software BHB-clearing sequences')
> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Except for the odd double "logic" in the title:
Reviewed-by: Jan Beulich <jbeul...@suse.com>
I can't really guess what is meant instead, so in order to possibly adjust
while committing I'll need a hint. But committing will want to wait until
Andrew has taken a look anyway, just like for patch 1.
> There (possibly) still a bit of overhead for dom0 if BHB clearing is not used
> for dom0, as Xen would still add the lfence if domUs require it.
Right, but what do you do.
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
> @@ -235,9 +235,6 @@ static inline bool boot_cpu_has(unsigned int feat)
> #define cpu_bug_fpu_ptrs boot_cpu_has(X86_BUG_FPU_PTRS)
> #define cpu_bug_null_seg boot_cpu_has(X86_BUG_NULL_SEG)
>
> -#define cpu_has_bhb_seq (boot_cpu_has(X86_SPEC_BHB_TSX) || \
> - boot_cpu_has(X86_SPEC_BHB_LOOPS))
Might be worth also mentioning in the description that this construct was
lacking use of X86_SPEC_BHB_LOOPS_LONG (might even warrant a 2nd Fixes:
tag).
Jan
