On 19/07/2023 10:44 am, Jan Beulich wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -118,6 +118,36 @@ config HVM
>  
>         If unsure, say Y.
>  
> +choice
> +     prompt "base psABI level"
> +     default X86_64_BASELINE
> +     help
> +       The psABI defines 4 levels of ISA extension sets as a coarse granular
> +       way of identifying advanced functionality that would be uniformly
> +       available in respectively newer hardware.  While v4 is not really of
> +       interest for Xen, the others can be selected here, making the
> +       resulting Xen no longer work on older hardware.  This option won't
> +       have any effect if the toolchain doesn't support the distinction.
> +
> +       If unsure, stick to the default.
> +
> +config X86_64_BASELINE
> +     bool "baseline"
> +
> +config X86_64_V2
> +     bool "v2"
> +     help
> +       This enables POPCNT and CX16, besides other extensions which are of
> +       no interest here.
> +
> +config X86_64_V3
> +     bool "v3"
> +     help
> +       This enables BMI, BMI2, LZCNT, MOVBE, and XSAVE, besides other
> +       extensions which are of no interest here.
> +
> +endchoice
> +
>  config XEN_SHSTK
>       bool "Supervisor Shadow Stacks"
>       depends on HAS_AS_CET_SS
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -36,6 +36,10 @@ CFLAGS += -mno-red-zone -fpic
>  # the SSE setup for variadic function calls.
>  CFLAGS += -mno-mmx -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
>  
> +# Enable the selected baseline ABI, if supported by the compiler.
> +CFLAGS-$(CONFIG_X86_64_V2) += $(call cc-option,$(CC),-march=x86-64-v2)
> +CFLAGS-$(CONFIG_X86_64_V3) += $(call cc-option,$(CC),-march=x86-64-v3)

I know we're having severe disagreements over Kconfig compiler checking,
but this patch cannot cannot go in in this form.

You're asking the user unconditionally for the psABI level, then
ignoring the answer on toolchains which don't understand it.

The makefile needs to be unconditional, and the Kconfig options need to
depend on suitable toolchain support.  This is the only way we don't get
a false statement written into the .config, and embedded in hypfs.

~Andrew

Reply via email to