- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

MFC r258399,258492:
mark aesni module _SYNC, improves performance ~27%...

Approved by: re (glebius)

MFC r257757:
fix issues w/ AES-NI on unaligned data blocks...

Approved by: re (kib)

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Use the fact that the AES-NI instructions can be pipelined to improve
performance... Use SSE2 instructions for calculating the XTS tweek
factor... Let the compiler do more work and handle register allocation
by using intrinsics, now only the key schedule is in assembly...

Replace .byte hard coded instructions w/ the proper instructions now
that both clang and gcc support them...

On my machine, pulling the code to userland I saw performance go from
~150MB/sec to 2GB/sec in XTS mode. GELI on GNOP saw a more modest
increase of about 3x due to other system overhead (geom and
opencrypto)...

These changes allow almost full disk io rate w/ geli...

Reviewed by: -current, -security
Thanks to: Mike Hamburg for the XTS tweek algorithm

When porting XTS-related code from OpenBSD I forgot to update copyright (only
OpenBSD was credited in one of two commits). Fix it.

Reported by: Theo de Raadt <deraadt@cvs.openbsd.org>
Reviewed by: Damien Miller <djm@mindrot.org>

Add support for the extended FPU states on amd64, both for native
64bit and 32bit ABIs. As a side-effect, it enables AVX on capable
CPUs.

In particular:

- Query the CPU support for XSAVE, list of the supported extensions
and the required size of FPU save area. The hw.use_xsave tunable is
provided for disabling XSAVE, and hw.xsave_mask may be used to
select the enabled extensions.

- Remove the FPU save area from PCB and dynamically allocate the
(run-time sized) user save area on the top of the kernel stack,
right above the PCB. Reorganize the thread0 PCB initialization to
postpone it after BSP is queried for save area size.

- The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as
well. FPU state is only useful for suspend, where it is saved in
dynamically allocated suspfpusave area.

- Use XSAVE and XRSTOR to save/restore FPU state, if supported and
enabled.

- Define new mcontext_t flag _MC_HASFPXSTATE, indicating that
mcontext_t has a valid pointer to out-of-struct extended FPU
state. Signal handlers are supplied with stack-allocated fpu
state. The sigreturn(2) and setcontext(2) syscall honour the flag,
allowing the signal handlers to inspect and manipilate extended
state in the interrupted context.

- The getcontext(2) never returns extended state, since there is no
place in the fixed-sized mcontext_t to place variable-sized save
area. And, since mcontext_t is embedded into ucontext_t, makes it
impossible to fix in a reasonable way. Instead of extending
getcontext(2) syscall, provide a sysarch(2) facility to query
extended FPU state.

- Add ptrace(2) support for getting and setting extended state; while
there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries.

- Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to
consumers, making it opaque. Internally, struct fpu_kern_ctx now
contains a space for the extended state. Convert in-kernel consumers
of fpu_kern KPI both on i386 and amd64.

First version of the support for AVX was submitted by Tim Bird
<tim.bird am sony com> on behalf of Sony. This version was written
from scratch.

Tested by: pho (previous version), Yamagi Burmeister <lists yamagi org>
MFC after: 1 month

Update Copyright.

MFC after: 3 days

Improve AES-NI performance for AES-XTS:
- Operate on uint64_t types when doing XORing, etc. instead of uint8_t.
- Don't bzero() temporary block for every AES block. Do it once for entire
data block.
- AES-NI is available only on little endian architectures. Simplify code
that takes block number from IV.

Benchmarks:

Memory-backed md(4) device, software AES-XTS, 4kB sector:

# dd if=/dev/md0.eli bs=1m
59.61MB/s

Memory-backed md(4) device, old AES-NI AES-XTS, 4kB sector:

# dd if=/dev/md0.eli bs=1m
97.29MB/s

Memory-backed md(4) device, new AES-NI AES-XTS, 4kB sector:

# dd if=/dev/md0.eli bs=1m
221.26MB/s

127% performance improvement between old and new code.

Harddisk, raw speed:

# dd if=/dev/ada0 bs=1m
137.63MB/s

Harddisk, software AES-XTS, 4kB sector:

# dd if=/dev/ada0.eli bs=1m
47.83MB/s (34% of raw disk speed)

Harddisk, old AES-NI AES-XTS, 4kB sector:

# dd if=/dev/ada0.eli bs=1m
68.33MB/s (49% of raw disk speed)

Harddisk, new AES-NI AES-XTS, 4kB sector:

# dd if=/dev/ada0.eli bs=1m
108.35MB/s (78% of raw disk speed)

58% performance improvement between old and new code.

As a side-note, GELI with AES-NI using AES-CBC can achive native disk speed.

MFC after: 3 days

Fix a bug in the result of manual assembly.

Reported by: Stefan Grundmann <sg2342 googlemail com>
PR: kern/155118
MFC after: 3 days

Remove DEBUG sections.

MFC after: 3 days

Only save FPU context when not executing in the context of the crypto
thread.

Tested by: Mike Tancsa

Change two missed instances of 'retq' in aeskeys_i386.S to 'retl', which
makes it possible to assemble this file with gas from newer binutils.

Reviewed by: kib

Fix two copy&paste bugs.

MFC after: 2 weeks

Add support for CRYPTO_AES_XTS.

MFC after: 1 week

Add support for CRD_F_KEY_EXPLICIT flag.

MFC after: 1 week

Simplify code a bit.

MFC after: 1 week

Crypto(4) driver for AESNI.

The aeskeys_{amd64,i386}.S content was mostly obtained from OpenBSD,
no objections to the license from core.

Hardware provided by: Sentex Communications
Tested by: fabient, pho (previous versions)
MFC after: 1 month