Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date:   Tue, 30 Mar 2021 13:20:27 -0700
Message-Id: <F2653B18-239A-42BB-84EE-04F18B712279@amacapital.net>
References: <d10affcb-d315-cebc-4162-084f0a1e4d43@intel.com>
Cc:     Len Brown <lenb@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        libc-alpha <libc-alpha@sourceware.org>,
        Florian Weimer <fweimer@redhat.com>,
        Rich Felker <dalias@libc.org>, Kyle Huey <me@kylehuey.com>,
        Keno Fischer <keno@juliacomputing.com>,
        Linux API <linux-api@vger.kernel.org>
In-Reply-To: <d10affcb-d315-cebc-4162-084f0a1e4d43@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Precedence: bulk


> On Mar 30, 2021, at 12:12 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>=20
> =EF=BB=BFOn 3/30/21 10:56 AM, Len Brown wrote:
>> On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski <luto@amacapital.net> wro=
te:
>>>> On Mar 30, 2021, at 10:01 AM, Len Brown <lenb@kernel.org> wrote:
>>>> Is it required (by the "ABI") that a user program has everything
>>>> on the stack for user-space XSAVE/XRESTOR to get back
>>>> to the state of the program just before receiving the signal?
>>> The current Linux signal frame format has XSTATE in uncompacted format,
>>> so everything has to be there.
>>> Maybe we could have an opt in new signal frame format, but the details w=
ould need to be worked out.
>>>=20
>>> It is certainly the case that a signal should be able to be delivered, r=
un =E2=80=9Casync-signal-safe=E2=80=9D code,
>>> and return, without corrupting register contents.
>> And so an an acknowledgement:
>>=20
>> We can't change the legacy signal stack format without breaking
>> existing programs.  The legacy is uncompressed XSTATE.  It is a
>> complete set of architectural state -- everything necessary to
>> XRESTOR.  Further, the sigreturn flow allows the signal handler to
>> *change* any of that state, so that it becomes active upon return from
>> signal.
>=20
> One nit with this: XRSTOR itself can work with the compacted format or
> uncompacted format.  Unlike the XSAVE/XSAVEC side where compaction is
> explicit from the instruction itself, XRSTOR changes its behavior by
> reading XCOMP_BV.  There's no XRSTORC.
>=20
> The issue with using the compacted format is when legacy software in the
> signal handler needs to go access the state.  *That* is what can't
> handle a change in the XSAVE buffer format (either optimized/XSAVEOPT,
> or compacted/XSAVEC).

The compacted format isn=E2=80=99t compact enough anyway. If we want to keep=
 AMX and AVX512 enabled in XCR0 then we need to further muck with the format=
 to omit the not-in-use features. I *think* we can pull this off in a way th=
at still does the right thing wrt XRSTOR.

If we go this route, I think we want a way for sigreturn to understand a poi=
nter to the state instead of inline state to allow programs to change the st=
ate.  Or maybe just to have a way to ask sigreturn to skip the restore entir=
ely.=