From: Agner Fog <agner@agner.org>
To: linux-kernel@vger.kernel.org
Subject: ABI change for device drivers using future AVX instruction set
Date: Wed, 25 Jun 2008 17:32:36 +0200 [thread overview]
Message-ID: <48626514.2040905@agner.org> (raw)
The announced future Intel AVX instruction set extends the 128-bit XMM
registers to 256-bit YMM registers.
Intel has proposed relevant ABI extensions, which I assume will be
adopted in the System V ABI. See references below.
Some details are not covered in the Intel documents. I have discussed
this with an Intel engineer who has supplied all the details I asked
for. I have listed the necessary ABI changes in detail in my manual on
calling conventions (see below).
One problem that has not been resolved yet, AFAIK, is how to handle the
possible use of YMM registers in device drivers. Should these registers
be saved before calling a device driver from an interrupt or should it
be the responsibility of the device driver?
This is particularly problematic for the following reasons:
1. The YMM registers must be saved with the new instruction XSAVE and
restored with XRESTOR if done in the device driver. Saving registers
individually will be incompatible with future extensions of the register
size to more than 256 bits.
2. There is a performance cost to using XSAVE / XRESTOR.
3. When compiling a device driver, the compiler may insert implicit
calls to library functions such as memcpy and memset. These functions
typically have a CPU dispatcher that chooses the largest register size
available. The device driver may therefore use YMM registers without the
knowledge of the programmer and without compiling with the AVX switch on.
4. The consequences of failing to save the YMM registers properly would
be intermittent and irreproducible errors that are difficult to trace.
The possible solutions, as I see it, are:
A. The operating system saves the state with XSAVE before calling a
device driver from an interrupt and restores with XRESTOR. The device
driver can use any register. This method is safe but has a performance
penalty.
B. The operating system disables the use of YMM registers with the
instruction XSETBV before calling a device driver from an interrupt. If
the device driver needs to use YMM registers it must save the state with
XSAVE before enabling YMM with XSETBV, and reverse these actions before
returning.
C. Make it the responsibility of the device driver to avoid the use of
YMM registers unless it saves the state with XSAVE. This solution
requires that available compilers have a switch to disable calls to
library functions with internal CPU dispatchers. Appears unsafe to me.
A decision on this question should be made and published in the ABI so
that people can make compatible device drivers.
Note:
Please Cc: me on this thread. I am not on this mailing list and I am not
involved with Linux development.
References:
Intel AVX programming reference:
http://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf
Intel proposed ABI extensions (very brief):
http://intel.wingateweb.com/SHchina/published/NGMS002/SP_NGMS002_100r_eng.pdf
My interpretation of the ABI extensions in detail:
http://www.agner.org/optimize/calling_conventions.pdf
My discussion with Mark Buxton, Intel
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30257153.aspx
next reply other threads:[~2008-06-25 16:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-25 15:32 Agner Fog [this message]
2008-06-25 16:22 ` ABI change for device drivers using future AVX instruction set Arjan van de Ven
2008-06-25 19:54 ` Agner Fog
2008-06-25 20:09 ` Arjan van de Ven
2008-06-26 1:11 ` H. Peter Anvin
2008-06-27 11:31 ` Agner Fog
2008-06-27 14:22 ` Arjan van de Ven
2008-06-28 8:05 ` Agner Fog
2008-06-28 8:10 ` David Miller
2008-06-28 11:47 ` Andi Kleen
2008-06-28 15:09 ` Agner Fog
2008-06-28 15:44 ` Helge Hafting
2008-06-28 20:02 ` Andi Kleen
2008-06-29 11:33 ` Avi Kivity
2008-06-29 12:21 ` Andi Kleen
2008-06-29 12:31 ` Avi Kivity
2008-06-29 13:07 ` Andi Kleen
2008-06-29 13:18 ` Avi Kivity
2008-06-29 13:23 ` Andi Kleen
2008-06-29 13:29 ` Avi Kivity
2008-06-29 22:08 ` H. Peter Anvin
2008-06-29 12:29 ` Alan Cox
2008-07-01 15:30 ` Arjan van de Ven
2008-06-25 20:14 ` Alan Cox
2008-06-26 14:01 ` Andi Kleen
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=48626514.2040905@agner.org \
--to=agner@agner.org \
--cc=linux-kernel@vger.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