On 15.02.2023 01:07, Boris Ostrovsky wrote: > > On 2/14/23 6:53 PM, Boris Ostrovsky wrote: >> >> On 2/14/23 11:13 AM, Jan Beulich wrote: >> >>> --- a/arch/x86/kernel/cpu/bugs.c >>> +++ b/arch/x86/kernel/cpu/bugs.c >>> @@ -18,6 +18,8 @@ >>> #include <linux/pgtable.h> >>> #include <linux/bpf.h> >>> +#include <xen/xen.h> >>> + >>> #include <asm/spec-ctrl.h> >>> #include <asm/cmdline.h> >>> #include <asm/bugs.h> >>> @@ -32,6 +34,7 @@ >>> #include <asm/intel-family.h> >>> #include <asm/e820/api.h> >>> #include <asm/hypervisor.h> >>> +#include <asm/xen/hypervisor.h> >>> #include <asm/tlbflush.h> >>> #include "cpu.h" >>> @@ -934,7 +937,8 @@ do_cmd_auto: >>> break; >>> case RETBLEED_MITIGATION_IBPB: >>> - setup_force_cpu_cap(X86_FEATURE_ENTRY_IBPB); >>> + if (!xen_pv_domain() || xen_vm_assist_ibpb(true)) >> >> >> Is this going to compile without CONFIG_XEN?
Yes. The declaration of xen_vm_assist_ibpb() is visible (satisfying the compiler) and DCE will eliminate the call to the function due to xen_pv_domain() being constant "false" in that case, avoiding any linking issues. The interesting case here really is building with XEN but without XEN_PV: That's why I needed to put the function in enlighten.c. This wouldn't be needed if xen_pv_domain() was also constant "false" in that case (just like xen_pvh_domain() is when !XEN_PVH). >> I also think these two conditions should be wrapped into something to limit >> exposure of non-Xen code to Xen-specific primitives. I would have done so, if I had any halfway sensible idea on how to go about doing so in this particular case. In the absence of that it looked okay-ish to me to reference Xen functions directly here. > Oh, and this needs x86 maintainers. Eventually yes. But I would prefer to sort the above question first (which I'm sure would have been raised by them, in perhaps more harsh a way), hence the initially limited exposure. Jan
