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;
MIME-Version: 1.0
References: <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu>
 <20210415054713.GB6318@zn.tnic> <CAJvTdKnjzAMh3N_c7KP3kA=e0LgYHgCANg44oJp3LcSm7dtbSQ@mail.gmail.com>
 <20210419141454.GE9093@zn.tnic> <CAJvTdK=p8mgO3xw9sRxu0c7NTNTG109M442b3UZh8TqLLfkC1Q@mail.gmail.com>
 <20210419191539.GH9093@zn.tnic> <CAJvTdK=VnG94ECcRVoUi8HrCbVEKc8X4_JmRTkqe+vTttf0Wsg@mail.gmail.com>
 <20210419215809.GJ9093@zn.tnic> <CAJvTdKn6JHo02karEs0e5g+6SimS5VUcXKjCkX35WY+xkgAgxw@mail.gmail.com>
 <YIMmwhEr46VPAZa4@zn.tnic> <CAJvTdKnhXnynybS4eNEF_EtF26auyb-mhKLNd1D9_zvCrchZsw@mail.gmail.com>
 <8735uxmucw.ffs@nanos.tec.linutronix.de> <CAJvTdK=6B8fXasshqOoMknAt25vWPDW6LVLovOhnmY10ZEdL1Q@mail.gmail.com>
 <eebc971a-dc5f-6ae6-c5f7-d303e56212b2@kernel.org>
In-Reply-To: <eebc971a-dc5f-6ae6-c5f7-d303e56212b2@kernel.org>
From:   Len Brown <lenb@kernel.org>
Date:   Thu, 20 May 2021 15:16:17 -0400
Message-ID: <CAJvTdKk3JvKzvEb+x9H-zSGEz9iSDQ=WdFLaOA38f+GxCPVj0g@mail.gmail.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
To:     Andy Lutomirski <luto@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>, Willy Tarreau <w@1wt.eu>,
        Florian Weimer <fweimer@redhat.com>,
        "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        Dave Hansen <dave.hansen@intel.com>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, linux-abi@vger.kernel.org,
        "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
        Rich Felker <dalias@libc.org>, Kyle Huey <me@kylehuey.com>,
        Keno Fischer <keno@juliacomputing.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, May 19, 2021 at 7:29 PM Andy Lutomirski <luto@kernel.org> wrote:

> > It is established that there exists application code that counts on
> > this opaque state being complete so that it can do a user-space
> > XRESTORE instead of a sigreturn(2).
>
> Is this established?
>
> Note that the specific case of a user program doing XRSTOR will work
> just fine if we omit the allocation of non-in-use states from the
> buffer, at least by my reading of the pseudocode.

Yes, your understanding is correct -- XRESTOR works as one would expect.

> The case that would
> break is if user code then assumes that it can XSAVE back to the same
> buffer.

The other case that would break is if the concept of what features
were supported
(eg. XCR0) changed between when the context was saved and when it was
subsequently restored.  Yes, if a feature appeared, you'd get INIT;
but if a feature went away, you would fault.

I've been told that user-space software exists that does this.  If I can find
specific examples, I'll share that.

thanks,
Len Brown, Intel Open Source Technology Center