The NeXTcube uses a normal 8530 serial controller, so we can simply use
our normal "escc" device here.
While we're at it, also add a boot-serial-test for the next-cube machine,
now that the serial output works.
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190831074519.32613-6-huth@tuxfamily.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Use the machine names specifiying the CPU type, POWER8 and POWER9.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190731141233.1340-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Make a new routine find_boot_device to locate the boot device for all
cases, not just virtio.
The error message for the case where no boot device has been specified
and a suitable boot device cannot be auto detected was specific to
virtio devices. We update this message to remove virtio specific wording.
Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <1554388475-18329-12-git-send-email-jjherne@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The new pseries-4.0 machine type defaults to enabling Spectre/Meltdown
mitigations. Unfortunately those mitigations aren't implemented for TCG
because we're not yet sure if they're necessary or how to implement them.
We don't fail fatally, but we do warn in this case, because it is quite
plausible that Spectre/Meltdown can be exploited through TCG (at least for
the guest to get access to the qemu address space).
This create noise in our testcases though. So, modify the affected tests
to explicitly disable the mitigations to suppress these warnings.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There's no point in waiting 5 full minutes when there will be
no more output. Compute timeout based on elapsed wall clock
time instead of N * delays, as the delay is a minimum sleep time.
Cc: Thomas Huth <thuth@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
[thuth: Replaced global_qtest with local qts variable]
Signed-off-by: Thomas Huth <thuth@redhat.com>
The test does not use any of the functions that require global_qtest,
so we can simply get rid of this global variable here.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
New mini-kernel test for nRF51 SoC UART.
Signed-off-by: Julia Suvorova <jusual@mail.ru>
Acked-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
OpenBIOS gained 40p support in 5b20e4cace
Use it, instead of relying on an unmaintained and very limited firmware.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
- prep machine is a fictional machine, so has no specifications. Which
devices can be changed/added/removed without impact? Are interrupts
correctly mapped?
- prep firmware (OHW) has support only for IDE drives (no SCSI).
Booting from IDE has been broken approximatively 3 years ago, and nobody complained.
- OHW is limited on IDE boot to a specific set of OS loaders.
These operating systems are of the 2004 time frame.
- OHW can use -kernel. Linux kernel freezes a long time after PS/2 mouse
detection, and then screen becomes garbage. This was already broken in
QEMU v2.7, 2 years ago, and nobody complained.
On the other side:
- 40p is a real machine, so emulation can be checked against
hardware specifications
- OpenBIOS has support for SCSI block devices, including 40p LSI adapter
- OpenBIOS can start mostly all Linux kernels (including recent ones)
and recent operating system (like NetBSD 7.1.2)
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
[dwg: Drop prep from boot-serial test to avoid deprecation warnings]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
On a SPARC host that I'm using as a build test machine, the
boot-serial-test for the SPARC guest machines takes about 65
seconds to execute. This means that it hits the current
60 second timer on these tests. Push the timeout up so
that it doesn't trigger spuriously on slow hosts like this one.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-id: 20180817161404.9420-1-peter.maydell@linaro.org
qtest_init() creates a new QTestState, and leaves @global_qtest alone.
qtest_start() additionally assigns it to @global_qtest, but
qtest_startf() additionally assigns NULL to @global_qtest. This makes
no sense. Replace it by qtest_initf() that works like qtest_init(),
i.e. leaves @global_qtest alone.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180806065344.7103-23-armbru@redhat.com>
Peter reported that the boot-serial tester sometimes runs into timeouts
with SPARC guests. It's currently completely unclear whether this is due
to too much load on the host machine (so that the guest really just ran
too slow), or whether there is something wrong with the guest's firmware
boot. For further debugging, we need the serial output of the guest in
case of errors, so instead of unlinking the file immediately, this is
now only done in case of success. In case of error, print the name of the
file with the serial output via g_error() (which then also calls abort()
internally to mark the test as failed).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1526977831-31129-1-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The consoles ("sclpconsole" and "sclplmconsole") can only be configured
with "-device" and "-chardev" so far. Other machines use the convenience
option "-serial" to configure the default consoles, even for virtual
consoles like spapr-vty on the pseries machine. So let's support this
option on s390x, too. This way we can easily enable the serial console
here again with "-nodefaults", for example:
qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio
... which is way shorter than typing:
qemu-system-s390x -no-shutdown -nographic -nodefaults \
-chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \
-mon chardev=c1
The -serial parameter can also be used if you only want to see the QEMU
monitor on stdio without using -nodefaults, but not the console output.
That's something that is pretty impossible with the current code today:
qemu-system-s390x -no-shutdown -nographic -serial none
While we're at it, this patch also maps the second -serial option to the
"sclplmconsole", so that there is now an easy way to configure this second
console on s390x, too, for example:
qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio
Additionally, the new code is also smaller than the old one and we have
less s390x-specific code in vl.c :-)
I've also checked that migration still works as expected by migrating
a guest with console output back and forth between a qemu-system-s390x
that has this patch and an instance without this patch.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1524754794-28005-1-git-send-email-thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We've got a U-Boot firmware for this board in our repository, and
the firmware prints some output to the serial console, so we can
check this board in the boot-serial tester, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The "40p" machine is using the Open Hack'Ware BIOS, just like the "prep"
machine, so we can test it accordingly with the boot-serial tester, too.
While we're at it, also change the strings that we are using for the
"prep" machine, so that this test now also checks some CLI parameters.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 92b540dac9 introduce a counter to handle the timeouts in a
better way. But in case ccnt reaches 512, the current read character is
ignored - and if that character is part of the string that we are looking
for, the test fails to match the string.
Almost all of the tests look for a string within the first 512 bytes of
firmware output, so the problem never triggered there. But the hppa test
that has been added recently looks for a longer string at the very end of
a long output, thus there's a chance that we miss a character there so
that the test fails unexpectedly. Fix it by *not* reading and dropping a
character if the counter reaches 512.
Fixes: 92b540dac9
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1518761564-9899-1-git-send-email-thuth@redhat.com
[PMM: added initializer for nbd to silence false-positive warning
from OpenBSD 6 compiler]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch adds a small binary kernel to test aarch64 virt machine's
UART.
Signed-off-by: Wei Huang <wei@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[thuth: Fixed contextual conflicts with the hppa and sdhci patches]
Signed-off-by: Thomas Huth <thuth@redhat.com>
OpenBIOS prints out the CPU type on these machine types, so we can use
this string to test whether the CPU detection is working correctly.
Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
OpenBIOS prints out the name of the detected CPU here, so looking for
this string is a nice test to verify that the CPU detection is still
working correctly.
Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Recent commit introduced the firmware image skiboot 5.9 which
has a different first line ouput.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The raspi2 machine supports loading firmware images, so we can easily
load a small test sequence as raw binary blob here to test the UART.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-8-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that moxiesim supports the -bios parameter, we can check this machine
in the boot-serial tester, too, by supplying a mini bios that only writes
'T' characters to the UART.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-7-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This adds two simple TCG + UART tests for the microblaze boards,
one in big endian mode, and one in little endian mode.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-5-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We can output a character quite easily here with some few lines of
assembly that we provide as a mini-kernel for this board.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-4-git-send-email-thuth@redhat.com>
[lv: add boot-serial-test in check-qtest-m68k]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
QEMU only ships with some few firmware images, i.e. we can currently run
the boot-serial test only on a very limited set of machines. But writing
some characters to the default UART of a machine can often be done with
some few lines of assembly, so we add the possibility to the boot-serial
tester to use its own mini-kernels or mini-firmwares. We write such images
then into a file that we can load with the "-kernel" or "-bios" parameter
when we launch QEMU.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-3-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If the guest continuesly writes characters to the UART, we never leave
the inner while loop and thus never check whether we've reached the
timeout value. So if we fail to find the expected string in the UART
output, the test just hangs and never finishs. Use a counter to regularly
break out of the while loop to check the timeout.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1512031988-32490-2-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We have several callers that were formatting the argument strings
themselves; consolidate this effort by adding new convenience
functions directly in libqtest, and update some call-sites that
can benefit from it.
Note that the new functions qtest_startf() and qtest_vstartf()
behave more like qtest_init() (the caller must assign global_qtest
after the fact, rather than getting it implicitly set). This helps
us prepare for future patches that get rid of the global variable,
by explicitly highlighting which tests still depend on it now.
Signed-off-by: Eric Blake <eblake@redhat.com>
[thuth: Dropped the hunks that do not apply cleanly to qemu master
yet and added the missing g_free(args) in qtest_vstartf()]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1508336428-20511-2-git-send-email-thuth@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Prefer to use the tcg accelarator if it is available: This is our only
real smoke test for tcg, and fast enough to use it for that.
Fixes: 480bc11e6 ("boot-serial-test: fallback to kvm accelerator")
Reported-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, at least x86_64 and s390x support building with --disable-tcg.
Instead of forcing tcg (which causes the test to fail on such builds),
allow to use kvm as well.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
a qemu with an empty s390 guest will exit very quickly. This races
against the testsuite reading from the console pipe leading to
intermittent test suite failures. Using -no-shutdown will keep
the guest running.
Fixes: 864111f422 (vl: exit qemu on guest panic if -no-shutdown is not set)
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-id: 1490361570-288658-1-git-send-email-borntraeger@de.ibm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A couple of tests for the work-in-progress 'powernv' machine type attempt
to test on POWER9 CPUs. However the POWER9 CPU support is incomplete and
this doesn't really work. In particular the firmware image we have
currently assumes the presence of the SDR1 register, which no longer exists
on POWER9. We only got away with this so far, because of a different bug
which added SDR1 to POWER9 even though it shouldn't be there.
For now, remove POWER9 testing of powernv, POWER8 testing will do for now
until the POWER9 support is more complete.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The new powernv machine ships with a firmware that outputs
some text to the serial console, so we can automatically
test this machine type in the boot-serial tester, too.
And to get some (very limited) test coverage for the new
POWER9 CPU emulation, too, this test is also started with
"-cpu POWER9".
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some of the machines that we have got a firmware image for write
some output to the serial console while booting up. We can use
this output to make sure that the machine is basically working,
so this adds a test that checks the output of these machines
for some well-known "magic" strings.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thomas Huth