Re: [PATCH 1/3] x86: allow Kconfig control over psABI level

From: Jason Andryuk <jandryuk@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 1/3] x86: allow Kconfig control over psABI level
Date: Mon, 17 Jul 2023 08:23:43 -0400	[thread overview]
Message-ID: <CAKf6xpvCFyQOqzekw7hV++yMPBDRCZxTagMQ7Fvbq244RrR9CA@mail.gmail.com> (raw)
In-Reply-To: <6f462a2f-2e91-6397-a527-18eeade19476@suse.com>

On Wed, Jul 12, 2023 at 8:34 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> Newer hardware offers more efficient and/or flexible and/or capable
> instructions, some of which we can make good use of in the hypervisor
> as well. Allow a basic way (no alternatives patching) of enabling their
> use. Of course this means that hypervisors thus built won't work
> anymore on older, less capable hardware.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Jason Andryuk <jandryuk@gmail.com>

With two comments.

> ---
> TBD: Should we, just like for NX, add an early check in assembly code,
>      to have a "clean" failure rather than a random crash?

That is less confusing than a random crash.

> Whereas the baseline -> v2 step isn't much of a difference (we'll gain
> more there by a subsequent patch), v2 -> v3, while presumably (or shall
> I say hopefully) faster, yields an overall growth of .text size by (in
> my build) about 2k. The primary reason for this appear to be conversions
> of SHL-by-immediate to SHLX.
>
> --- 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, and MOVBE, besides other extensions
> +         which are of no interest here.

Would it make sense to try and specify models?  According to this:
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

x86-64-v2
(circa 2009: Nehalem and Jaguar)
Atom Silvermont (2013)
VIA Nano and Eden "C" (2015)

x86-64-v3
(circa 2015: Haswell and Excavator)
Atom Gracemont (2021)

Regards,
Jason