aboutsummaryrefslogtreecommitdiff
path: root/tests/boot-serial-test.c
AgeCommit message (Collapse)Author
2020-01-12test: Move qtests to a separate directoryThomas Huth
The tests directory itself is pretty overcrowded, and it's hard to see which test belongs to which test subsystem (unit, qtest, ...). Let's move the qtests to a separate folder for more clarity. Message-Id: <20191218103059.11729-6-thuth@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-12-17vl: configure accelerators from -accel optionsPaolo Bonzini
Drop the "accel" property from MachineState, and instead desugar "-machine accel=" to a list of "-accel" options. This has a semantic change due to removing merge_lists from -accel. For example: - "-accel kvm -accel tcg" all but ignored "-accel kvm". This is a bugfix. - "-accel kvm -accel thread=single" ignored "thread=single", since it applied the option to KVM. Now it fails due to not specifying the accelerator on "-accel thread=single". - "-accel tcg -accel thread=single" chose single-threaded TCG, while now it will fail due to not specifying the accelerator on "-accel thread=single". Also, "-machine accel" and "-accel" become incompatible. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-09-07m68k: Add serial controller to the NeXTcube machineThomas Huth
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>
2019-08-29tests/boot-serial-test: add support for all the PowerNV machinesCédric Le Goater
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>
2019-04-12s390-bios: Factor finding boot device out of virtio code pathJason J. Herne
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>
2019-03-12Suppress test warnings about missing Spectre/Meltdown mitigations with TCGDavid Gibson
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>
2018-12-17tests: Exit boot-serial-test loop if child diesRichard Henderson
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>
2018-12-17tests/boot-serial: Get rid of global_qtest variableThomas Huth
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>
2018-11-02tests/boot-serial-test: Add microbit board testcaseJulia Suvorova
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>
2018-09-25hw/ppc: on 40p machine, change default firmware to OpenBIOSHervé Poussineau
OpenBIOS gained 40p support in 5b20e4cacecb62fb2bdc6867c11d44cddd77c4ff 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>
2018-08-21hw/ppc: deprecate the machine type 'prep', replaced by '40p'Hervé Poussineau
- 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>
2018-08-20tests/boot-serial-test: Bump timeout to 6 minutesPeter Maydell
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
2018-08-16libqtest: Replace qtest_startf() by qtest_initf()Markus Armbruster
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>
2018-06-29tests/boot-serial: Do not delete the output file in case of errorsThomas Huth
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>
2018-04-30hw/s390x: Allow to configure the consoles with the "-serial" parameterThomas Huth
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>
2018-04-10tests/boot-serial: Test the sam460ex boardThomas Huth
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>
2018-03-18tests/boot-serial: Check the 40p machine, tooThomas Huth
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>
2018-02-16tests/boot-serial-test: Fix problem with timeout due to dropped charactersThomas Huth
Commit 92b540dac9fc3a5 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: 92b540dac9fc3a572c7342edd0b073000f5a6abf 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>
2018-02-14tests/boot-serial-test: Add support for the aarch64 virt machineWei Huang
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>
2018-02-14tests/boot-serial: Add tests for PowerPC Mac machinesThomas Huth
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>
2018-02-14tests/boot-serial: Enable the boot-serial test on SPARC machines, tooThomas Huth
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>
2018-02-04tests: Enable boot-serial-test for hppaRichard Henderson
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-01-17tests/boot-serial-test: fix powernv supportCédric Le Goater
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>
2018-01-16tests/boot-serial-test: Add support for the raspi2 machineThomas Huth
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>
2018-01-16tests/boot-serial-test: Add a test for the moxiesim machineThomas Huth
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>
2018-01-16tests/boot-serial-test: Add tests for microblaze boardsThomas Huth
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>
2017-12-21tests/boot-serial-test: Add support for the mcf5208evb boardThomas Huth
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>
2017-12-21tests/boot-serial-test: Add code to allow to specify our own kernel or biosThomas Huth
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>
2017-12-21tests/boot-serial-test: Make sure that we check the timeout regularlyThomas Huth
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>
2017-10-20libqtest: Add qtest_[v]startf()Eric Blake
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>
2017-08-22boot-serial-test: prefer tcg acceleratorCornelia Huck
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>
2017-08-11boot-serial-test: fallback to kvm acceleratorCornelia Huck
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>
2017-03-24boot-serial-test: use -no-shutdownChristian Borntraeger
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: 864111f422ba (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>
2017-03-03powernv: Don't test POWER9 CPU yetDavid Gibson
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>
2016-11-15boot-serial-test: Add a test for the powernv machineThomas Huth
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>
2016-09-07tests: Check serial output of firmware boot of some machinesThomas Huth
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>