Currently test/run uses wildcards to run all of the tests in a directory.
However, that wildcard list is filtered down by the "onlyfor" directives
in the test files... usually to a single file.

Therefore, just explicitly list the files we *really* want to run for this
test mode.  This makes it easier to see at the top level what tests will
be executed, and to change that list temporarily while debugging specific
failures.

This means the "onlyfor" directive no longer has any purpose, and we can
remove it.  "onlyfor" was also the only used of the $MODE variable, so we
can remove that too.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Move the download of mbuto and using it to create a sample initramfs to
the asset build makefile, rather than embedding it in the test scripts
themselves.

The two_guests tests used to use two separate copies of the mbuto
image.  As an initramfs the mbuto image is strictly readonly though,
so that's not necessary.  So, also use the same image for both guests.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

A lot of tests and examples invoke qemu with the command "kvm".  However,
as far as I can tell, "kvm" being aliased to the appropriate qemu system
binary is Debian specific.  The binary names from qemu upstream -
qemu-system-$ARCH - also aren't universal, but they are more common (they
should be good for both Debian and Fedora at least).

In order to still get KVM acceleration when available, we use the option
"-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that
order

A number of the places we invoked "kvm" are expecting specifically an x86
guest, and so it's also safer to explicitly invoke qemu-system-x86_64.

Some others appear to be independent of the target arch (just wanting the
same arch as the host to allow KVM acceleration).  Although I suspect there
may be more subtle x86 specific options in the qemu command lines, attempt
to preserve arch independence by using $(uname -m).

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

This depends on a future change in mbuto to accept external profile
files. Add a file defining what we need for tests and demos, dropping
udhcpc and script as they're not needed anymore, and switch to it.

Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

For some reason, the passt/pasta tests and examples use dhclient for
DHCPv6, but in most cases use udhcpc for DHCPv4.  Change it to use dhclient
for both DHCPv4 and DHCPv6.  This means one less tool we need for testing,
plus dhclient is easily available on Fedora whereas udhcpc is not.

Note that the passt tests still rely on udhcpc indirectly because mbuto
wants to put it into the guest images it generates.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

A number of tests and examples use dhclient in both IPv4 and IPv6 modes.
We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4.  Add
an explicit "-4" argument to make it more clear and explicit.

In addition, when dhclient is run from within pasta it usually won't be
"real" root, and so will not have access to write the default global pid
file.  This results in a mostly harmless but irritating error:
    Can't create /var/run/dhclient.pid: Permission denied
We can avoid that by using the --no-pid flag to dhclient.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

ip(8)'s ability to take abbreviated arguments (e.g. "li sh" instead of
"link show") is very handy when using it interactively, but it doesn't make
for very readable scripts and examples when shown that way.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

When we use pane_wait to wait for a command issued to a tmux pane to finish
we have no idea whether the command succeeded or not.  This means that the
test scripts can keep running long after the point something vital has
failed, making it difficult to work out what went wrong.

Add a new pane_status command that checks for success of the issued command
and use it in most places instead of pane_wait.  We still need explicit
pane_wait where we're gathering explicit output with pane_parse, because
the way we check the status with 'echo $?' means we lose track of that
output.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio:
 - instead of quitting the script, make a test fail if a command
    issued in a pane fails during a test, and loop until the status code is
    numeric in pane_status() as a hack to make it a bit more robust
 - retain usage of pane_wait() in iperf3 and teardown functions as we
   interrupt iperf3, passt, and pasta, so a non-zero exit code is expected
 - drop bogus ns_{1,2}_wait() calls in teardown_two_guests(), those
   functions were never implemented
 - use pane_status() for "guest" test directives too
]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

The project is now at mbuto.sh, and git transport is enabled.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Pass to seccomp.sh a list of additional syscalls valgrind needs as
EXTRA_SYSCALLS in a new 'valgrind' make target, and add corresponding
support in seccomp.sh itself.

In test setup functions, start passt with valgrind, but not for
performance tests.

Add tests checking that valgrind exits without errors after all the
other tests in the group are done.

Signed-off-by: Stefano Brivio <sbrivio@redhat.com>