From: "Andy Lutomirski" <luto@kernel.org>
To: "Thomas Gleixner" <tglx@linutronix.de>,
"Florian Weimer" <fweimer@redhat.com>,
"Dave Hansen" <dave.hansen@intel.com>
Cc: "Dave Hansen via Libc-alpha" <libc-alpha@sourceware.org>,
"Len Brown" <lenb@kernel.org>, "Rich Felker" <dalias@libc.org>,
"Linux API" <linux-api@vger.kernel.org>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Kyle Huey" <me@kylehuey.com>, "Borislav Petkov" <bp@alien8.de>,
"Keno Fischer" <keno@juliacomputing.com>,
"Arjan van de Ven" <arjan@linux.intel.com>,
"Willy Tarreau" <w@1wt.eu>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
Date: Fri, 21 May 2021 13:07:52 -0700 [thread overview]
Message-ID: <6c9c4597-a1af-4cbb-9dc8-424999d04793@www.fastmail.com> (raw)
In-Reply-To: <87k0nraonu.ffs@nanos.tec.linutronix.de>
On Fri, May 21, 2021, at 12:10 PM, Thomas Gleixner wrote:
> On Fri, May 21 2021 at 09:31, Andy Lutomirski wrote:
> > arch_prctl(SET_XSTATE_INIT_ON_FIRST_USE, TILE_STUFF);?
> >
> > As long as this is allowed to fail, I don’t have a huge problem with
> > it.
>
> I'm fine with that. It's still controlled by the OS and can return
> -EPERM.
>
> If allowed then the application would also accept to be insta killed if
> that #NM allocation fails. Any bug report vs. that will be ignored.
>
> > I think several things here are regrettable:
> >
> > 1. Legacy XSTATE code might assume that XCR0 is a constant.
> >
> > 2. Intel virt really doesn’t like us context switching XCR0, although
> > we might say that this is Intel’s fault and therefore Intel’s
> > problem. AMD hardware doesn’t appear to have this issue.
> >
> > 3. AMX bring tangled up in XSTATE is unfortunate. The whole XSTATE
> > mechanism is less than amazing.
> >
> > IMO the best we can make of this whole situation is to make XCR0
> > dynamic, but the legacy compatibility issues are potentially
> > problematic.
>
> Why? The bit can be enabled and #NM catches the violation of the ABI
> contract if the application did not request usage. No XCR0 fiddling on
> context switch required.
>
> Thanks,
>
> tglx
>
>
>
XFD does nothing about signals. It also doesn’t help give applications a non-Linux-specific way to ask if AMX is available. The SDM says that one can read XCR0. Sure, we can use it, but cross platform libraries seem likely to get it wrong.
next prev parent reply other threads:[~2021-05-21 20:08 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210415044258.GA6318@zn.tnic>
[not found] ` <20210415052938.GA2325@1wt.eu>
[not found] ` <20210415054713.GB6318@zn.tnic>
[not found] ` <CAJvTdKnjzAMh3N_c7KP3kA=e0LgYHgCANg44oJp3LcSm7dtbSQ@mail.gmail.com>
[not found] ` <20210419141454.GE9093@zn.tnic>
[not found] ` <CAJvTdK=p8mgO3xw9sRxu0c7NTNTG109M442b3UZh8TqLLfkC1Q@mail.gmail.com>
[not found] ` <20210419191539.GH9093@zn.tnic>
[not found] ` <CAJvTdK=VnG94ECcRVoUi8HrCbVEKc8X4_JmRTkqe+vTttf0Wsg@mail.gmail.com>
[not found] ` <20210419215809.GJ9093@zn.tnic>
[not found] ` <CAJvTdKn6JHo02karEs0e5g+6SimS5VUcXKjCkX35WY+xkgAgxw@mail.gmail.com>
[not found] ` <YIMmwhEr46VPAZa4@zn.tnic>
[not found] ` <CAJvTdKnhXnynybS4eNEF_EtF26auyb-mhKLNd1D9_zvCrchZsw@mail.gmail.com>
2021-05-17 9:45 ` Candidate Linux ABI for Intel AMX and hypothetical new related features Thomas Gleixner
2021-05-17 9:56 ` Florian Weimer
2021-05-17 10:18 ` Thomas Gleixner
2021-05-21 16:29 ` Len Brown
2021-05-17 13:49 ` Arjan van de Ven
2021-05-20 15:35 ` Len Brown
2021-05-20 20:54 ` Thomas Gleixner
2021-05-20 21:13 ` Dave Hansen
2021-05-20 21:41 ` Len Brown
2021-05-20 22:53 ` Dave Hansen
2021-05-21 9:41 ` Thomas Gleixner
2021-05-21 14:44 ` Florian Weimer
2021-05-21 14:49 ` Peter Zijlstra
2021-06-23 15:06 ` Florian Weimer
2021-06-23 23:11 ` Len Brown
2021-06-28 10:14 ` Enrico Weigelt, metux IT consult
2021-06-28 12:49 ` Florian Weimer
2021-06-30 12:22 ` Enrico Weigelt, metux IT consult
2021-06-30 12:41 ` Willy Tarreau
2021-06-30 13:55 ` Arjan van de Ven
2021-06-30 15:20 ` Len Brown
2021-06-30 15:25 ` Enrico Weigelt, metux IT consult
2021-05-21 16:14 ` Dave Hansen
2021-05-21 16:19 ` Florian Weimer
2021-05-21 16:26 ` Len Brown
2021-05-21 16:28 ` Dave Hansen
2021-05-21 16:31 ` Andy Lutomirski
2021-05-21 19:10 ` Thomas Gleixner
2021-05-21 20:07 ` Andy Lutomirski [this message]
2021-05-21 21:43 ` Thomas Gleixner
2021-05-21 22:07 ` Len Brown
2021-05-21 22:46 ` Thomas Gleixner
2021-05-21 23:31 ` Len Brown
2021-05-22 7:16 ` Florian Weimer
2021-05-22 23:55 ` Andy Lutomirski
2021-05-21 23:06 ` Dave Hansen
2021-05-21 23:08 ` Len Brown
2021-05-21 19:05 ` Thomas Gleixner
2021-05-20 21:22 ` Len Brown
2021-05-20 21:41 ` Thomas Gleixner
2021-05-20 21:49 ` Len Brown
2021-05-21 9:26 ` Thomas Gleixner
[not found] <CALCETrW2QHa2TLvnUuVxAAheqcbSZ-5_WRXtDSAGcbG8N+gtdQ@mail.gmail.com>
2021-03-26 23:18 ` Andy Lutomirski
2021-03-27 3:39 ` Len Brown
2021-03-27 9:14 ` Borislav Petkov
2021-03-27 9:58 ` Greg KH
2021-03-29 15:47 ` Len Brown
2021-03-29 16:38 ` Len Brown
2021-03-29 16:48 ` Florian Weimer
2021-03-29 18:14 ` Andy Lutomirski
2021-03-29 18:16 ` Andy Lutomirski
2021-03-29 22:38 ` Len Brown
2021-03-30 5:08 ` Andy Lutomirski
2021-03-30 5:50 ` Noah Goldstein
2021-03-30 17:01 ` Len Brown
2021-03-30 17:05 ` Andy Lutomirski
2021-03-30 17:56 ` Len Brown
2021-03-30 19:12 ` Dave Hansen
2021-03-30 20:20 ` Andy Lutomirski
2021-03-30 20:42 ` Len Brown
2021-03-30 22:01 ` David Laight
2021-03-31 16:31 ` Len Brown
2021-03-31 16:53 ` Andy Lutomirski
2021-03-31 21:42 ` Robert O'Callahan
2021-03-31 22:11 ` Len Brown
2021-03-31 22:28 ` Len Brown
2021-03-31 22:45 ` Andy Lutomirski
2021-04-09 20:52 ` Len Brown
2021-04-09 21:44 ` Andy Lutomirski
2021-04-11 19:07 ` Len Brown
2021-04-12 7:59 ` David Laight
2021-04-12 12:19 ` Borislav Petkov
2021-04-12 17:14 ` Sean Christopherson
2021-03-31 22:52 ` Borislav Petkov
2021-04-09 20:55 ` Len Brown
2021-03-28 0:53 ` Thomas Gleixner
2021-03-29 7:27 ` Peter Zijlstra
2021-03-29 15:06 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c9c4597-a1af-4cbb-9dc8-424999d04793@www.fastmail.com \
--to=luto@kernel.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dalias@libc.org \
--cc=dave.hansen@intel.com \
--cc=fweimer@redhat.com \
--cc=keno@juliacomputing.com \
--cc=lenb@kernel.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@kylehuey.com \
--cc=tglx@linutronix.de \
--cc=w@1wt.eu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).