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

From: Jan Beulich <jbeulich@suse.com>
To: Jason Andryuk <jandryuk@gmail.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 15:35:00 +0200	[thread overview]
Message-ID: <3f413bfc-ba5d-5370-f474-8036f5f1c02f@suse.com> (raw)
In-Reply-To: <CAKf6xpvCFyQOqzekw7hV++yMPBDRCZxTagMQ7Fvbq244RrR9CA@mail.gmail.com>

On 17.07.2023 14:23, Jason Andryuk wrote:
> 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>

Thanks.

> 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.

Of course. My thinking behind not doing this right away was that people
aren't supposed to use such a hypervisor on incapable hardware. So we
would likely add code for something which ought to never happen. Still
for v2 I guess I'll add such code (then of course invalidating your R-b
again); in the worst case it should be easy to rip out again from the
patch.

>> --- 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)

I'm not sure how useful this would be without supplying a reasonably
complete list of models. I don't think we can expect people to be aware
of the sequence of model names, without which specifying just the first
respective models isn't very useful.

Jan