Apparently qemu's ARM virt machine needs to be explicitly given a firmware
image, rather than just supplying a sane default. Unfortunately the EDK2
firmware image we need isn't in the same place on all host distros.
Currently the test scripts hardcode the Debian location, meaning it will
break on hosts that have it somewhere else. This patch searches multiple
locations for the firmware, and creates a local link during the asset build
phase, which the tests can then use.
For now it only searches the locations used by Debian and Fedora, but
that's a small improvement in robustness already, and can be later improved
further if we need to.
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>
Several tests run pp64le guests using "qemu-system-ppc64le". But, at the
system level there's no difference between ppc64 and ppc64le - it's the
same hardware, just placed into different endian modes by OS early boot
code. Reflecting that, qemu only supplies a single "qemu-system-ppc64".
Some distros alias qemu-system-ppc64le to qemu-system-ppc64 (Debian does),
but it's best not to count on this (Fedora doesn't, for example).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There are several places which explicitly list the various generated
binaries, even though a $(BIN) variable already lists them. There are
several more places that list all the manpage files, introduce a
$(MANPAGES) variable to remove that repetition as well.
Tweak the generation of pasta.1 as a link to passt.1 so it's not just made
as a side effect of the pasta target.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: add passt.1 and qrap.1 to guest files for distro tests]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
A number of individual test cases use '*out' commands to check for success
of specific commands they've issued. Now that the test harness is testing
for success of all issued commands as a matter of course, we no longer need
to do this.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The shell might report 'nc -6 -l -p 9999 > /tmp/ns_msg' as done
even after the subsequent 'echo' is done: wait one second before
reading out /tmp/ns_msg, to ensure we read that instead of the
"Done" message.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
The new tests check build and a simple case with pasta sending a
short message in both directions (namespace to init, init to
namespace).
Tests cover a mix of Debian, Fedora, OpenSUSE and Ubuntu combinations
on aarch64, i386, ppc64, ppc64le, s390x, x86_64.
Builds tested starting from approximately glibc 2.19, gcc 4.7, and
actual functionality approximately from 4.4 kernels, glibc 2.25,
gcc 4.8, all the way up to current glibc/gcc/kernel versions.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
