Get rid of static Atffiles and let bsd.test.mk generate them on the fly.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

Add tests for process_xmm_to_s87() and process_s87_to_xmm()

New test sys/crypto/aes/t_aes.

Runs aes_selftest on all kernel AES implementations supported on the
current hardware, not just the preferred one.

tests for network address printers.

Get rid of static Atffiles and let bsd.test.mk generate them on the fly.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

Add kernel ChaCha test to exercise all available implementations.

New test sys/crypto/aes/t_aes.

Runs aes_selftest on all kernel AES implementations supported on the
current hardware, not just the preferred one.

Needs the same compiler bug workaround as the kernel.

aes(9): Rewrite x86 SSE2 implementation.

This computes eight AES_k instances simultaneously, using the
bitsliced 32-bit aes_ct logic which computes two blocks at a time in
uint32_t arithmetic, vectorized four ways.

Previously, the SSE2 code was a very naive adaptation of aes_ct64,
which computes four blocks at a time in uint64_t arithmetic, without
any 2x vectorization -- I did it at the time because:

(a) it was easier to get working,
(b) it only affects really old hardware with neither AES-NI nor SSSE3
which are both much much faster.

But it was bugging me that this was a kind of dumb use of SSE2.

Substantially reduces stack usage (from ~1200 bytes to ~800 bytes)
and should approximately double throughput for CBC decryption and for
XTS encryption/decryption.

I also tried a 2x64 version but cursory performance measurements
didn't reveal much benefit over 4x32. (If anyone is interested in
doing more serious performance measurements, on ancient hardware for
which it might matter, I also have the 2x64 code around.)

Prompted by:

PR kern/59774: bearssl 32-bit AES is too slow, want 64-bit optimized
version in kernel

aes(9): New 64-bit bitsliced implementation.

Derived from BearSSL's aes_ct64 code. Compared to the aes_ct code,
on machines with native 64-bit integer arithmetic, aes_ct64 should
have approximately:

- the same throughput for:
. CBC encryption,
. CCM encryption/decryption, and
. CBC-MAC;

- double the throughput for:
. CBC decryption,
. XTS encryption/decryption.

(aes_ct computes AES on two blocks at a time; aes_ct64 computes it on
four blocks at a time, with roughly the same number of instructions.
CBC encryption and CBC-MAC are inherently sequential; CCM, being a
combination of CTR and CBC-MAC, can only really be parallelized two
ways, so having four ways available doesn't help; and CBC decryption
and XTS admit parallelism limited only by the size of the inputs.)

Enable with `options AES_BEAR64'. Should be a reasonable default on
all platforms with 64-bit integer registers. Caveat: uses about 1200
bytes of stack space. (Could approximately halve that, like the
BearSSL aes_ct code, at some speed cost which I haven't measured --
by moving the br_aes_ct64_skey_expand logic into add_round_key in
aes_ct64_{enc,dec}.c.)

PR kern/59774: bearssl 32-bit AES is too slow, want 64-bit optimized
version in kernel

aes(9): New aes_keysched_enc/dec.

These implement the standard key schedule. They are named
independently of any particular AES implementation, so that:

(a) we can swap between the BearSSL aes_ct and aes_ct64 code without
changing all the callers who don't care which one they get, and

(b) we could push it into the aes_impl abstraction if we wanted.

This eliminates all br_aes_* references outside aes_bear.c, aes_ct*.c,
and the new aes_keysched.c wrappers.

Preparation for:

PR kern/59774: bearssl 32-bit AES is too slow, want 64-bit optimized
version in kernel

introduce new GCC 12 warning disables and use them in a few places

this introduces 4 new warning disable flags:

CC_WNO_MISSING_TEMPLATE_KEYWORD
CC_WNO_REGISTER
CC_WNO_STRINGOP_OVERREAD
CC_WNO_ARRAY_BOUNDS

and documents them in README.warnings. of these, the string op
and array bounds are both problematic (real bugs) and also spurious
(not real bugs), and the other 2 are mostly temporary for older
3rd party code.

add some new uses of CC_WNO_STRINGOP_OVERFLOW.

fix m68k build for gallium and GCC 12.

Acknowledge clang warning for NEON cipher code on aarch64eb

We've already made the nonportable vector initializations portable; the
code works on aarch64eb.

Make the AES and ChaCha NEON tests work in softfloat userland.

(`Softfloat' here refers to the ABI, which of course may be running
on a CPU with NEON.)

Restrict the NEON code to v7hf - the softfloat toolchain does not like
it (nor is it likely to work if there is no FPU present).

Implement AES-CCM with ARMv8.5-AES.

Pass the requisite -msse options for i386.

New test sys/crypto/aes/t_aes.

Runs aes_selftest on all kernel AES implementations supported on the
current hardware, not just the preferred one.

aes(9): Rewrite x86 SSE2 implementation.

This computes eight AES_k instances simultaneously, using the
bitsliced 32-bit aes_ct logic which computes two blocks at a time in
uint32_t arithmetic, vectorized four ways.

Previously, the SSE2 code was a very naive adaptation of aes_ct64,
which computes four blocks at a time in uint64_t arithmetic, without
any 2x vectorization -- I did it at the time because:

(a) it was easier to get working,
(b) it only affects really old hardware with neither AES-NI nor SSSE3
which are both much much faster.

But it was bugging me that this was a kind of dumb use of SSE2.

Substantially reduces stack usage (from ~1200 bytes to ~800 bytes)
and should approximately double throughput for CBC decryption and for
XTS encryption/decryption.

I also tried a 2x64 version but cursory performance measurements
didn't reveal much benefit over 4x32. (If anyone is interested in
doing more serious performance measurements, on ancient hardware for
which it might matter, I also have the 2x64 code around.)

Prompted by:

PR kern/59774: bearssl 32-bit AES is too slow, want 64-bit optimized
version in kernel

aes(9): New 64-bit bitsliced implementation.

Derived from BearSSL's aes_ct64 code. Compared to the aes_ct code,
on machines with native 64-bit integer arithmetic, aes_ct64 should
have approximately:

- the same throughput for:
. CBC encryption,
. CCM encryption/decryption, and
. CBC-MAC;

- double the throughput for:
. CBC decryption,
. XTS encryption/decryption.

(aes_ct computes AES on two blocks at a time; aes_ct64 computes it on
four blocks at a time, with roughly the same number of instructions.
CBC encryption and CBC-MAC are inherently sequential; CCM, being a
combination of CTR and CBC-MAC, can only really be parallelized two
ways, so having four ways available doesn't help; and CBC decryption
and XTS admit parallelism limited only by the size of the inputs.)

Enable with `options AES_BEAR64'. Should be a reasonable default on
all platforms with 64-bit integer registers. Caveat: uses about 1200
bytes of stack space. (Could approximately halve that, like the
BearSSL aes_ct code, at some speed cost which I haven't measured --
by moving the br_aes_ct64_skey_expand logic into add_round_key in
aes_ct64_{enc,dec}.c.)

PR kern/59774: bearssl 32-bit AES is too slow, want 64-bit optimized
version in kernel

Make the AES and ChaCha NEON tests work in softfloat userland.

(`Softfloat' here refers to the ABI, which of course may be running
on a CPU with NEON.)

Sort includes.

Add missing include to fix the build on architectures w/o any special
accelerated AES implementation.

New test sys/crypto/aes/t_aes.

Runs aes_selftest on all kernel AES implementations supported on the
current hardware, not just the preferred one.

apply previous to just GCC.

apply -Wno-maybe-uninitialized to chacha_sse2.c.

there's a clearly initialised memory region that is claimed as
being maybe uninitialised, and this test-build version of it
triggers it while the normal build doesn't.

Acknowledge clang warning for NEON cipher code on aarch64eb

We've already made the nonportable vector initializations portable; the
code works on aarch64eb.

Make the AES and ChaCha NEON tests work in softfloat userland.

(`Softfloat' here refers to the ABI, which of course may be running
on a CPU with NEON.)

Restrict the NEON code to v7hf - the softfloat toolchain does not like
it (nor is it likely to work if there is no FPU present).

Implement 4-way vectorization of ChaCha for armv7 NEON.

cgd performance is not as good as I was hoping (~4% improvement over
chacha_ref.c) but it should improve substantially more if we let the
cgd worker thread keep fpu state so we don't have to pay the cost of
isb and zero-the-fpu on every 512-byte cgd block.

Enable ChaCha NEON code on armv7 too.

The 4-blocks-at-a-time assembly helper is disabled for now; adapting
it to armv7 is going to be a little annoying with only 16 128-bit
vector registers.

(Should also do a fifth block in the integer registers for 320 bytes
at a time.)

Add kernel ChaCha test to exercise all available implementations.

Make the AES and ChaCha NEON tests work in softfloat userland.

(`Softfloat' here refers to the ABI, which of course may be running
on a CPU with NEON.)

It's __ARM_NEON, not __ARM_NEON__, sometimes, apparently.

Enable ChaCha NEON code on armv7 too.

The 4-blocks-at-a-time assembly helper is disabled for now; adapting
it to armv7 is going to be a little annoying with only 16 128-bit
vector registers.

(Should also do a fifth block in the integer registers for 320 bytes
at a time.)

Add kernel ChaCha test to exercise all available implementations.

Fix TESTSDIR

tests for network address printers.

catch up with link printing.

tests for network address printers.

bsd.own.mk: rename GCC_NO_* to CC_WNO_*

Rename compiler-warning-disable variables from
GCC_NO_warning
to
CC_WNO_warning
where warning is the full warning name as used by the compiler.

GCC_NO_IMPLICIT_FALLTHRU is CC_WNO_IMPLICIT_FALLTHROUGH

Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.

add some new uses of existing GCC_NO_* variables for warning issues.
remove an no longer relevant for gcc7 workaround (works fine in both
gcc9 and gcc 10.)

tests for network address printers.

tests for network address printers.

tests for network address printers.

Add casts for big endian machines

tests for network address printers.

tests for network address printers.

Add casts for big endian machines

tests for network address printers.

Get rid of static Atffiles and let bsd.test.mk generate them on the fly.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

Get rid of static Atffiles and let bsd.test.mk generate them on the fly.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

Fix various typos, mainly in comments.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

tests: replace deprecated '-s eq:...' with '-s exit:...'

Mark randomly failing test cases as expected failures with a reference
to PR bin/56506.

Adjusts tests after import of atf-0.12:

- The use.fs property is gone.
- Mark the tests/fs/t_create:attrs test as broken when using the default
unprivileged-user:_atf setting. This probably deserves a fix somehow
but I'm not sure at this point.

atf-0.9 introduces an use.fs test-case property to allow tests to write to
their work directory. The purpose is to be able to know which tests intend
to touch the file system and to allow a minor optimization in atf-run.

Define use.fs=true for all those tests requiring it. (This highlights that
some tests currently require modifying the file system but conceptually
they shouldn't be... which leaves room for further improvements/cleanups
later :-)

Fix execution of the installed tests by using h_{simple,args} as program
names, without the .sh extension.

Add some basic tests for rc.d scripts to validate the execution of
subcommands and the optional argument passing to them from the command
line.

Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.

branches: 1.1.2;
This is a preview of the uvm_hotplug(9) api code.
This commit does not actually introduce the UVM_HOTPLUG option.
However it does provide developers a way to review, test and try out
the API.

To do this, please go to tests/sys/uvm/ and build and run the tests
there. The tests also have a set of basic load tests, to get a measure
of the performance penalties due to enabling the UVM_HOTPLUG option.

In order to build the tests you need to have at least done the
following in $SRC/

cd $SRC; $NBMAKE do-distrib-dirs includes
cd $SRC/lib/csu; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc_s; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc; $NBMAKE all install || exit
cd $SRC/lib/libc; $NBMAKE includes all install || exit
cd $SRC/lib/libpthread; $NBMAKE all install || exit
cd $SRC/lib/libm; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libstdc++-v3/; $NBMAKE all install || exit

Once the development environment has these userspace libraries, one
can simple build using $NBMAKE and finally test the kernel API using

atf-run|atf-report

s/fucntion/function/ in comments.

s/existant/existent/ in comments and messages, plus few more similar fixes.

s/bacause/because/

Fixed issues with uvm_page_physunload_delete_end test case.

1. "avail_start" and "start" were different, resulting in unreachable code in
uvm_page_physunload(), where the condition check "avail_start" < "end" fails.
The test has been fixed by setting "avail_start" and "start" to the same value.

2. If "start" is the address with end address being "start + 2", we can
unplug twice, the first paddr_t would be "start" and the second one would be
"start + 1". Modified the ATF_CHECK_EQ() to reflect these changes.

Reviewed by <cherry>

Fixed issues with uvm_physseg_atboot_free_leak test case.

"\n" in ATF discriptions make it behave in weird ways, like saying "this
test is bogus.", fixed the issue by removing the "\n".

Reviewed by <cherry>

Fixed issues with uvm_physseg_plug test case.

There is a condition check which failed for VM_PHYSSEG_MAX == 2 (not for
1 or 3 and above), in case of 2, pgs == slab + npages1 + npages3, so we
need to change ">" check to ">=" check.

Reviewed by <cherry>

Fixed the build failures caused by incompatible type comparisons when
VM_PHYSSEG is > 1.

Reviewed by <cherry>

Fixed the build failures caused by incompatible type comparisons.

Reviewed by <cherry>

branches: 1.3.2; 1.3.4;
Typos.

branches: 1.2.2;
convention about function names for predicate checking:
s/uvm_physseg_valid()/uvm_physseg_valid_p()/

per. matt@

This is a preview of the uvm_hotplug(9) api code.
This commit does not actually introduce the UVM_HOTPLUG option.
However it does provide developers a way to review, test and try out
the API.

To do this, please go to tests/sys/uvm/ and build and run the tests
there. The tests also have a set of basic load tests, to get a measure
of the performance penalties due to enabling the UVM_HOTPLUG option.

In order to build the tests you need to have at least done the
following in $SRC/

cd $SRC; $NBMAKE do-distrib-dirs includes
cd $SRC/lib/csu; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc_s; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc; $NBMAKE all install || exit
cd $SRC/lib/libc; $NBMAKE includes all install || exit
cd $SRC/lib/libpthread; $NBMAKE all install || exit
cd $SRC/lib/libm; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libstdc++-v3/; $NBMAKE all install || exit

Once the development environment has these userspace libraries, one
can simple build using $NBMAKE and finally test the kernel API using

atf-run|atf-report

s/fucntion/function/ in comments.

branches: 1.2.2;
convention about function names for predicate checking:
s/uvm_physseg_valid()/uvm_physseg_valid_p()/

per. matt@

This is a preview of the uvm_hotplug(9) api code.
This commit does not actually introduce the UVM_HOTPLUG option.
However it does provide developers a way to review, test and try out
the API.

To do this, please go to tests/sys/uvm/ and build and run the tests
there. The tests also have a set of basic load tests, to get a measure
of the performance penalties due to enabling the UVM_HOTPLUG option.

In order to build the tests you need to have at least done the
following in $SRC/

cd $SRC; $NBMAKE do-distrib-dirs includes
cd $SRC/lib/csu; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc_s; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libgcc/libgcc; $NBMAKE all install || exit
cd $SRC/lib/libc; $NBMAKE includes all install || exit
cd $SRC/lib/libpthread; $NBMAKE all install || exit
cd $SRC/lib/libm; $NBMAKE all install || exit
cd $SRC/external/gpl3/gcc/lib/libstdc++-v3/; $NBMAKE all install || exit

Once the development environment has these userspace libraries, one
can simple build using $NBMAKE and finally test the kernel API using

atf-run|atf-report

Add tests for process_xmm_to_s87() and process_s87_to_xmm()

Add tests for process_xmm_to_s87() and process_s87_to_xmm()