I am sponsoring the following fast-track for Lejun Zhu and Kuriakose
Kuruvilla. It requests a patch/micro binding. Man pages with change
bars are available in the materials directory. Timeout is set to
8/11/2010.
Thanks,
Sherry
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Support Intel Advanced Vector Extensions (AVX) in Solaris
1.2. Name of Document Author/Supplier:
Lejun Zhu
Kuriakose Kuruvilla
1.3. Date of This Document:
Jul 14th, 2010
1.4. Name of Major Document Customer(s)/Consumer(s):
1.4.1. The Community you expect to review your project:
1.4.2. The ARC(s) you expect to review your project:
// Leave blank if you don't have any preference
// This item is advisory only
1.5. Email Aliases:
1.5.2. Responsible Engineer:
<lejun....@intel.com>
<kuriakose.kuruvi...@oracle.com>
1.5.4. Interest List: intel-c...@sun.com
2. Project Summary
2.1. Project Description:
Intel Advanced Vector Extensions (AVX) introduces new instructions
that accelerate vector floating point operations. AVX uses 256-bit
registers, which requires extension of current Solaris interfaces that
manipulate FPU registers, such as signal stack layout, "setcontext"
syscall and /proc interface.
2.2. Risks and Assumptions:
When extending Solaris interfaces and/or data structures to
support AVX, it is very important to provide binary compatibility for
existing applications. All application binaries that exist today will
continue to run on new Solaris kernel without having to be recompiled. The
only restriction for existing binaries is that they have enough space on
the signal stack to hold the extra state (see 4.1.2 for details).
3. Business Summary
3.1. Problem Area:
Intel AVX is a new 256-bit SIMD FP vector extension of Intel
Architecture. Its introduction is targeted for the next Intel
Microarchitecture (code named: Sandy Bridge). Intel AVX accelerates the
trends towards FP intensive computation in general purpose applications
like image, video, and audio processing, engineering applications such as
3D modeling and analysis, scientific simulation, and financial analytics.
3.2. Market/Requester:
3.3. Business Justification:
Customers who use Solaris x86 will expect to run optimized
applications on Sandy Bridge and future generations of Intel CPU, and many
optimizations will use AVX instructions, such as Basic Linear Algebra
Subprograms (BLAS) with DGEMM Routine, or sequential and cluster FFTs.
Also, the amd64 ABI has already supported YMM registers. Latest GCC can
generate AVX instructions, and an AVX-enabled Sun Studio compiler is being
developed. All of these will require kernel changes to support AVX.
3.4. Competitive Analysis:
Support for XSAVE and YMM has already been implemented in Linux kernel.
3.5. Opportunity Window/Exposure:
Intel will support AVX instructions in the next generation Intel
Microarchitecture (code-named: Sandy Bridge). Applications optimized for
Sandy Bridge will emerge soon. In order to enable these optimizations on
Solaris, we need to get the OS support into ON as soon as possible.
3.6. How will you know when you are done?:
Applications can run correctly and use YMM registers on Intel machines
that support AVX/YMM registers.
4. Technical Description:
4.1. Details:
4.1.1 Extending ucontext_t
Structure ucontext_t will have the same size as its previous
version and all existing fields will be at the same byte offset, except
part of its filler is used for xregs extension. A new flag UC_XREGS (0x10)
for the uc_flags field will be added. Any ucontext_t with this flag set is
considered to have the new layout described in this PSARC case. Any
ucontext_t with this flag not set in its uc_flags is considered to have
the original layout and its uc_xrs field will be ignored.
A data structure will be defined as follows for both 32-bit
and 64-bit applications:
#define XRS_ID 0x00737278 /* the string "xrs" */
typedef struct {
unsigned long xrs_id;
caddr_t xrs_ptr;
} xrs_t;
Field xrs_id must have the value XRS_ID (little endian), and
xrs_ptr will point to a prxregset_t data structure.
Part of uc_filler in current ucontext_t definition will be
used to store xrs_t. The new definition of ucontext_t is:
typedef struct ucontext {
unsigned long uc_flags;
ucontext_t *uc_link;
sigset_t uc_sigmask;
stack_t uc_stack;
mcontext_t uc_mcontext;
xrs_t uc_xrs;
long uc_filler[3];
} ucontext_t;
For 64-bit kernel to work with 32-bit application, the
following definition will be used:
typedef struct {
uint32_t xrs_id;
caddr32_t xrs_ptr;
} xrs32_t;
typedef struct ucontext32 {
uint32_t uc_flags;
caddr32_t uc_link;
sigset32_t uc_sigmask;
stack32_t uc_stack;
mcontext32_t uc_mcontext;
xrs32_t uc_xrs;
int32_t uc_filler[3];
} ucontext32_t;
Only the kernel components that are specified in this PSARC
case will use the extended form of ucontext_t. The rest of kernel code
that uses ucontext_t, for example getcontext() calls, will remain
unchanged, which means flag UC_XREGS will always be cleared in uc_flags,
and uc_xrs will be filled with 0 (if it is a kernel created ucontext_t) in
these unchanged cases.
There is an alternative way to store xrs_t in ucontext_t,
which is putting xrs_t into fpregset_t of mcontext_t. But there is no
trailing padding bytes in the amd64 definition of fpregset_t, therefore we
will have to use the software available bytes (defined in table "XSAVE
Save Area Layout for x87 FPU and SSE State" of Intel Software Developer's
Manual Volume 2B) and put xrs_t in the middle of fpregset_t (before
"status" and "xstatus"). In the i386 definition, the layout of fpregset_t
is different - there are no software available bytes, but there is
trailing space because fp_emul is larger than fpchip_state. Putting the
same field in different orders in the amd64 and i386 definition will make
it less straightforward in C declaration. Also, since XSAVE is designed to
be an generic mechanism capable of saving more than FPU state, putting
xrs_t in fpregset_t will look strange if we have non-FPU state in the
future. In Solaris implementation whenever we do a selective copy in of
fpregset_t we will need to change the code to always copy in xrs_t in
fpregset_t, which makes it even more confusing. So using uc_filler is the
better way to extend uccontext_t without changing the size of any existing
data structure.
Data type prxregset_t is defined as:
#define XR_TYPE_XSAVE 0x101
typedef struct prxregset {
uint32_t pr_type;
uint32_t pr_align;
uint32_t pr_xsize;
uint32_t pr_pad;
union {
struct pr_xsave {
uint16_t pr_fcw;
uint16_t pr_fsw;
uint16_t pr_fctw;
uint16_t pr_fop;
#if defined(__amd64)
uint64_t pr_rip;
uint64_t pr_rdp;
#else
uint32_t pr_eip;
uint16_t pr_cs;
uint16_t __pr_ign0;
uint32_t pr_dp;
uint16_t pr_ds;
uint16_t __pr_ign1;
#endif
uint32_t pr_mxcsr;
uint32_t pr_mxcsr_mask;
union {
uint16_t pr_fpr_16[5];
u_longlong_t pr_fpr_mmx;
uint32_t __pr_fpr_pad[4];
} pr_st[8];
#if defined(__amd64)
upad128_t pr_xmm[16];
upad128_t __pr_ign2[3];
#else
upad128_t pr_xmm[8];
upad128_t __pr_ign2[11];
#endif
union {
struct {
uint64_t pr_xcr0;
uint64_t pr_mbz[2];
} pr_xsave_info;
upad128_t __pr_pad[3];
} pr_sw_avail;
uint64_t pr_xstate_bv;
uint64_t pr_rsv_mbz[2];
uint64_t pr_reserved[5];
#if defined(__amd64)
upad128_t pr_ymm[16];
#else
upad128_t pr_ymm[8];
upad128_t __pr_ign3[8];
#endif
} pr_xsave;
} pr_un;
} prxregset_t;
Field pr_type and pr_align are derived from SPARC prxregset_t
definition. Field pr_type will have the value XR_TYPE_XSAVE indicating
that this data structure is defined as in this PSARC case. Field pr_align
is currently unused and should be set to 0. The value of field pr_xsize
will be equal to the size of the union member selected by the pr_type, in
this case sizeof (struct pr_xsave). pr_pad will make the layout of
prxregset_t identical under 32-bit and 64-bit compilers, its value is
ignored by the kernel and should be set to 0.
Field pr_xsave is used to store XSAVE/AVX specific state. The
first 512 byte part is the same as FXSAVE layout (the same as the amd64
definition of fpregset_t, see also the FXSAVE instruction in Intel
Software Developer's Manual Volume 2A), followed by 64 byte XSAVE header
and 256 byte YMM state. See table "General Layout of XSAVE/XRSTOR Save
Area" in Intel Software Developer's Manual Volume 2B for detailed meaning
of each new field in XSAVE layout. Field pr_sw_avail represents the
software available bytes defined in table "XSAVE Save Area Layout for x87
FPU and SSE State" of Intel Software Developer's Manual Volume 2B, and is
used to store additional information. Its field pr_xcr0 contains the value
of XCR0 of the CPU when the state is saved, the rest of the area should be
set to 0.
The YMM registers are always 256 bits in length for both
32-bit and 64-bit code. The lower part (bit 127-0) of the YMM registers is
mapped onto the corresponding XMM registers. pr_ymm only stores the upper
part (bit 255-128), and the lower part is stored in pr_xmm as they used to
be. This is consistent with the XSAVE layout used by the CPU. All 16 YMM
registers are available in 64-bit code, but 32-bit code can only access
first 8 YMM registers.
4.1.1.1 Future extensibility
The definition of prxregset_t is extendable. In case of a
future extension, for example adding a 512 byte state XYZ into the
context, the definition will be:
typedef struct prxregset {
uint32_t pr_type;
uint32_t pr_align;
uint32_t pr_xsize;
uint32_t pr_pad;
union {
struct pr_xsave {
uint16_t pr_fcw;
uint16_t pr_fsw;
uint16_t pr_fctw;
uint16_t pr_fop;
#if defined(__amd64)
uint64_t pr_rip;
uint64_t pr_rdp;
#else
uint32_t pr_eip;
uint16_t pr_cs;
uint16_t __pr_ign0;
uint32_t pr_dp;
uint16_t pr_ds;
uint16_t __pr_ign1;
#endif
uint32_t pr_mxcsr;
uint32_t pr_mxcsr_mask;
union {
uint16_t pr_fpr_16[5];
u_longlong_t pr_fpr_mmx;
uint32_t __pr_fpr_pad[4];
} pr_st[8];
#if defined(__amd64)
upad128_t pr_xmm[16];
upad128_t __pr_ign2[3];
#else
upad128_t pr_xmm[8];
upad128_t __pr_ign2[11];
#endif
union {
struct {
uint64_t pr_xcr0;
uint64_t pr_mbz[2];
} pr_xsave_info;
upad128_t __pr_pad[3];
} pr_sw_avail;
uint64_t pr_xstate_bv;
uint64_t pr_rsv_mbz[2];
uint64_t pr_reserved[5];
#if defined(__amd64)
upad128_t pr_ymm[16];
#else
upad128_t pr_ymm[8];
upad128_t __pr_ign3[8];
#endif
uint8_t pr_xyz[512];
} pr_xsave;
} pr_un;
} prxregset_t;
As a general rule, when extending prxregset_t as defined in
this PSARC case, all existing fields should be kept in the same byte
offset within prxregset_t, unless the value of pr_type is changed as well.
The kernel will verify the integrity of data structure "pxr"
and convert an earlier version to latest version using the following
pseudo code:
prxregset_t *pxr; /* Possibly earlier version of xregs */
prxregset_t kxr; /* Latest definition of xregs in kernel */
/* FXSAVE + XSAVE header + YMM */
size_t size_avx = 512 + 64 + 256;
size_t size_xyz = size_avx + 512; /* AVX + XYZ */
if (pxr->pr_type != XR_TYPE_XSAVE) {
/* pxr is invalid */
}
If (pxr->pr_xsize < size_avx) {
/* pxr is invalid */
}
if ((pxr->pr_un.pr_xsave.pr_xstate_bv & XFEATURE_XYZ) &&
pxr->pr_xsize < size_xyz) {
/* pxr is invalid */
}
bcopy(&pxr->pr_un.pr_xsave, &kxr.pr_un.pr_xsave, 512);
if (pxr->pr_un.pr_xsave.pr_xstate_bv & XFEATURE_AVX) {
bcopy(&pxr->pr_un.pr_xsave.pr_ymm,
&kxr.pr_un.pr_xsave.pr_ymm,
sizeof (kxr.pr_un.pr_xsave.pr_ymm));
}
if (pxr->pr_un.pr_xsave.pr_xstate_bv & XFEATURE_XYZ) {
bcopy(&pxr->pr_un.pr_xsave.pr_xyz,
&kxr.pr_un.pr_xsave.pr_xyz,
sizeof (kxr.pr_un.pr_xsave.pr_xyz));
}
Applications are encouraged to use the value in pr_xsize to
work with future prxregset_t extensions. When pr_xyz is added, such
applications that are developed before XYZ extension can still work, for
example, to copy a prxregset_t structure in memory to a file by
calculating the number of bytes to copy using pr_xsize.
4.1.2 Signal stack
An amd64 signal frame looks like this on the stack:
old %rsp:
<128 bytes of untouched stack space>
<a siginfo_t [optional]>
<a prxregset_t [optional]> (added by this PSARC case)
<a ucontext_t>
<siginfo_t *>
<signal number>
new %rsp: <return address (deliberately invalid)>
An i386 SVR4/ABI signal frame looks like this on the stack:
old %esp:
<a siginfo32_t [optional]>
<a prxregset_t [optional]> (added by this PSARC case)
<a ucontext32_t>
<pointer to that ucontext32_t>
<pointer to that siginfo32_t>
<signo>
new %esp: <return address (deliberately invalid)>
User space code will access siginfo_t and ucontext_t through
pointers, so the signature of signal handler is not changed. This PSARC
case adds a prxregset_t to the signal frame if the system supports AVX.
The existence of prxregset_t can be determined from the uc_flags and
uc_xrs of ucontext_t.
On AVX enabled systems, this extension will appear on every
application that has its FPU state enabled, even if the application does
not use AVX or YMM registers. As the result, some additional space in the
signal handler stack will be used (sizeof prxregset_t, which is 848 bytes
for now).
4.1.3 Getsetcontext syscall
Syscall "getsetcontext" (100) will be extended to deal with
the new ucontext_t. On AVX enabled machines, YMM is considered part of FPU
state. If UC_XREGS and UC_FPU are found in uc_flags, and xrs_id and
pr_xsize are valid, SETCONTEXT will update the LWP's FPU state using the
content in prxregset_t.
GETCONTEXT will not be extended, because all YMM registers are
caller saved. Compiler generated code or assembly programmer should
restore YMM registers when the called function returns. When the
application tries to restore the context saved by GETCONTEXT, the
application will continue to execute from the next instruction after
setcontext() if UC_CPU is not set, or from the next instruction after
previous getcontext() if UC_CPU is set. In both cases, the YMM registers
should be restored by compiler generated code or hand written assembly.
Therefore it is not necessary for GETCONTEXT to return YMM content.
As a result, the kernel code branch to process the extended
SETCONTEXT will only be executed when UC_XREGS is set, which happens only
when SETCONTEXT is called at the end of libc signal handling routine.
Normal calls of libc setcontext() from user application do not have
UC_XREGS set, and SETCONTEXT will work the same way as before.
4.1.4 /proc
File /proc/<pid>/lwp/<id>/xregs will be used to support
read/write of extra state (XSTATE_BV and YMM for now) through the procfs
interface. The following functions in x86 architecture will be added:
PCSXREG (procfs ioctl)
The length of /proc/<pid>/lwp/<id>/xregs will be sizeof
(prxregset_t) on machines that support AVX, and 0 on other machines.
On machines that support AVX, the content of
/proc/<pid>/lwp/<id>/xregs will be the same as "<a prxregset_t
[optional]>" that is placed on signal stack.
When using PCSXREG to set extra state, user space application
must provide a prxregset_t that is valid under the integrity check, and is
meaningful on current machine. In this PSARC case, prxregset_t will be
considered invalid if the values of these fields: pr_type or pr_xsize
fails the sanity check defined in 4.1.1.1. Trying to set an invalid
prxregset_t or set YMM in a system that does not support AVX will not
change the state of the target process. In such situations, EINVAL will be
returned. This is different from the behavior in SPARC implementation,
which does not verify the content of prxregset_t.
The value of pr_xcr0 is informational and should not be
modified when application modifies state through procfs.
The bit values in pr_xstate_bv indicate the corresponding area
of the FPU state that should be set (bit X = 1) or initialized (bit X =
0). When bit X is set to 0, values in corresponding area will be ignored
and initial values will be set into FPU instead. For the meaning of each
bit, see the operation section of XRSTOR instruction in Intel Software
Developer's Manual Volume 2B.
4.1.4.1 Future extensibility of procfs
Considering the general rules to extend prxregset_t in
4.1.1.1, it is safe for applications that are developed today to
read/write xregs on a future Solaris version. For example, an application
which reads xregs, update ymm0 and write it back can do the following:
prxregset_t *pxr;
struct pr_xsave *pxs;
size_t len;
/* FXSAVE + XSAVE header + YMM */
size_t size_avx = 512 + 64 + 256;
len = get_file_size("/proc/123/lwp/1/xregs");
if (len < size_avx) {
//The system does not have xregs extension with
//AVX state. Stop.
}
pxr = (prxregset_t *)malloc(len);
read_entire_file("/proc/123/lwp/1/xregs", pxr);
// Sanity check.
if (pxr->pr_type != XR_TYPE_XSAVE) {
//Not the xregs type we want, stop.
}
pxs = &pxr->pr_un.pr_xsave;
if ((pxs->pr_sw_avail.pr_xsave_info.pr_xcr0 &
XFEATURE_AVX) == 0) {
//This system does not have AVX. Stop.
}
if (!pxs->pr_xstate_bv & XFEATURE_AVX) {
//YMM is in initial state, clean and set.
memset(pxs->pr_ymm,
0, sizeof (pxs->pr_ymm));
pxs->pr_xstate_bv |= XFEATURE_AVX;
}
//Update pxs->pr_ymm[0]
ioctl_set_xregs("/proc/123/lwp/1/xregs", pxr);
4.1.5 Core dump format
We already have prxregset_t as part of the core dump file (see
core(4)). On x86 systems that have xregs extension, e.g. the systems that
have enabled AVX extension, the core dump will include note sections with
prxregset_t as described in the manpage.
To support dumping xregs using gcore(1), libproc needs to be
extended by adding SPARC specific APIs to x86 definition as well. Because
libproc is only used privately by tools such as dtrace and gcore, this
will not cause compatibility issues.
4.1.6 mdb(1)
mdb(1) will support disassembling all the new AVX
instructions, as well as XSAVE, XRESTORE, XGETBV and XSETBV. Also, mdb(1)
will be able to process YMM values as part of the FPU state in the same
way as we have for XMM today. On platforms that support AVX, mdb(1) "print
floating point registers" commands ($x and $y) will print the %ymm value
for each %xmm that is printed. An example of mdb output is:
> $x
_fp_hw 0x03 (80387 chip with SSE)
< ...omitted >
%xmm0 0x5f4d4d585f4d4d585f4d4d585f4d4d58
%xmm1 0x00000000000000000000000000000000
%xmm2 0x00000000000000000000000000000000
%xmm3 0x00000000000000000000000000000000
%xmm4 0x00000000000000000000000000000000
%xmm5 0x00000000000000000000000000000000
%xmm6 0x00000000000000000000000000000000
%xmm7 0x00000000000000000000000000000000
%ymm0
0x5f4d4d595f4d4d595f4d4d595f4d4d595f4d4d585f4d4d585f4d4d585f4d4d58
%ymm1
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm2
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm3
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm4
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm5
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm6
0x0000000000000000000000000000000000000000000000000000000000000000
%ymm7
0x0000000000000000000000000000000000000000000000000000000000000000
4.1.7 Hardware Capabilities
Two new hardware capability bits, AV_386_XSAVE (0x10000000)
and AV_386_AVX (0x20000000) are added. Applications that needs to be aware
of XSAVE and AVX can test the hardware capabilities on the current system
to see if it supports these features.
4.1.8 Linux Brand
Solaris 10 has a Lx Brand that supports an earlier version of
Linux kernel, which doesn't have AVX or XSAVE support. In Nevada, it has
been removed by PSARC/2010/169. So, nothing needs to be changed in Linux
Brand for now. However, changes will be required in the Lx Brand in the
future if we upgrade the Linux kernel to a version that supports AVX.
4.2. Bug/RFE Number(s):
6714685 Need to support Intel Advanced Vector Extensions (AVX)
Also the following CRs are related to this PSARC:
6958308 XSAVE/XRSTOR mechanism to save and restore processor state
6970220 Replace use of XSAVE with XSAVEOPT instruction for optimized
context saves
4.3. In Scope:
Kernel changes necessary to support the use of AVX instructions
and YMM registers in user space.
4.4. Out of Scope:
Debuggers and tools other than mdb(1) to manipulate YMM.
4.5. Interfaces:
Interface Stability
--------- ---------
Data structure:
ucontext_t / ucontext32_t Evolving
xrs_t / xrs32_t Evolving
prxregset_t Evolving
Procfs ioctl:
PCSXREG Evolving
User space API:
proc_service:
ps_lgetxregsize Evolving
ps_lgetxregs Evolving
ps_lsetxregs Evolving
thread_db:
td_thr_getxregsize Evolving
td_thr_getxregs Evolving
td_thr_setxregs Evolving
libproc:
Plwp_getxregs Evolving
Plwp_setxregs Evolving
4.6. Doc Impact:
As xregs is introduced in x86 architecture as well, the following
manpages needs to be updated. All changed man pages can be found in
attachment. Modified versions of these man pages have change bars.
ps_lgetregs(3PROC)
proc_service(3PROC)
td_thr_getgregs(3C_DB)
4.7. Admin/Config Impact:
N/A
4.8. HA Impact:
N/A
4.9. I18N/L10N Impact:
N/A
4.10. Packaging & Delivery:
N/A
4.11. Security Impact:
We need to prevent YMM state to be "leaked" between processes,
because these registers may contain sensitive information. Currently we
always set or initialize all FPU state (legacy FP, XMM and YMM) during
context switch when using XRSTOR. In signal stack handling, we keep YMM
values untouched if UC_XREGS is not set in ucontext_t. This is the same as
how we handle the rest of FPU state today if UC_FPU is not set.
4.12. Dependencies:
N/A
5. Reference Documents:
Intel Advanced Vector Extensions Programming Reference
Document #319433, www.intel.com
Chapter 3 System Programming Model: OS requirement to support AVX.
Intel 64 and IA-32 Architectures Software Developer's Manual
Document #253667, www.intel.com
XSAVE layout.
System V Application Binary Interface
AMD64 Architecture Processor Supplement
Draft Version 0.99, www.x86-64.org
Section 3.2: ABI requirement for YMM.
6. Resources and Schedule:
6.1. Projected Availability:
3Q '10
6.2. Cost of Effort:
The implementation and unit testing will take 1 engineer and 3
months. Also it will take 1 engineer and 3 months for integration and back
port.
6.4. Product Approval Committee requested information:
6.4.1. Consolidation or Component Name: ON (OS/Net)
6.4.7. Target RTI Date/Release:
OpenSolaris build 147
6.4.8. Target Code Design Review Date:
6.5. ARC review type:
Fast track
6.6. ARC Exposure: open
6.6.1. Rationale: Part of OpenSolaris
7. Prototype Availability:
7.1. Prototype Availability:
Prototype currently available
7.2. Prototype Cost:
2 person-weeks required to verify implementation
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
