To test the RISC-V IOMMU emulation we'll use its PCI representation.
Create a new 'riscv-iommu-pci' libqos device that will be present with
CONFIG_RISCV_IOMMU. This config is only available for RISC-V, so this
device will only be consumed by the RISC-V libqos machine.
Start with basic tests: a PCI sanity check and a reset state register
test. The reset test was taken from the RISC-V IOMMU spec chapter 5.2,
"Reset behavior".
More tests will be added later.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241016204038.649340-8-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add GPIO test cases to test output and input pins from A0 to D7 for AST2700.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[ clg: - Updated MAINTAINERS ]
Signed-off-by: Cédric Le Goater <clg@redhat.com>
The ide-test occasionally times out: on the system I run
vm-build-openbsd on, it usually takes about 18 seconds, but
occasionally hits the 60s timeout, likely when the host machine is
under heavy load. I have also seen this test hit its time limit on
the s390x CI runner.
Double the timeout for this test so that it won't hit its timeout
even when the host is running more slowly than usual.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241015113705.239067-1-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The qmp-cmd-test test takes typically about 15s on my local machine.
On the k8s runners it takes usually 20s but sometimes about 60s,
because the k8s runners have wildly variable execution time. If
they're running slow, we hit the default timeout. Bump the
qmp-cmd-test timeout to 120s to avoid this.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20241008141337.2790423-1-peter.maydell@linaro.org
Since the "shix" machine has been removed, the "r2d" machine is the only
machine that is still available for the sh4 and sh4eb targets. However,
the "r2d" machine apparently does not work in big endian mode, see here:
https://lore.kernel.org/qemu-devel/87a5fwjjew.wl-ysato@users.sourceforge.jp/
So there is no working machine left in the sh4eb-softmmu target, i.e. it
is currently completely useless. Thus remove it from the configuration
now. (Note: The linux-user binary is not removed since it might still
be used to run sh4 binaries in big endian mode).
Message-ID: <20240926105843.81385-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The numa-test needs a default machine in the target binary to work
successfully, so don't try to run this test if the corresponding
machine has not been enabled, e.g. when QEMU has been configured with
"--without-default-devices".
Message-ID: <20240905191434.694440-7-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When configuring QEMU with "--without-default-devices", currently a lot
of the x86 qtests are failing since they silently assume that a certain
device or the i440fx pc machine is available. Add more checks for CONFIG
switches here to not run those tests in case the corresponding device is
not available.
Message-ID: <20240905191434.694440-6-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
In this commit Write a qtest pnv-spi-seeprom-test to check the
SPI transactions between spi controller and seeprom device.
Signed-off-by: Chalapathi V <chalapathi.v@linux.ibm.com>
Acked-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Caleb Schlossin <calebs@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
pkix_asn1_tab[] is only accessed by crypto-tls-x509-helpers.c,
rename pkix_asn1_tab.c as pkix_asn1_tab.c.inc and include it once.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[berrange: updated MAINTAINERS for changed filename]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
CI often fails 'cross-i686-tci' job due to runner slowness
Log shows that test almost complete, with a few remaining
when bios-tables-test timeout hits:
19/270 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test
TIMEOUT 610.02s killed by signal 15 SIGTERM
...
stderr:
TAP parsing error: Too few tests run (expected 8, got 7)
At the same time overall job running time is only ~30 out of 1hr allowed.
Increase bios-tables-test instance timeout on 5min as a fix
for slow CI runners.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-ID: <20240716125930.620861-1-imammedo@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The dbus_display1_dep is not really used since all occurrences also
request gio independently. Just list the generated sources and drop
dbus_display1_dep.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The testcase contains :
- `test_idr_reset_value()` :
Checks the reset values of MODER, OTYPER, PUPDR, ODR and IDR.
- `test_gpio_output_mode()` :
Checks that writing a bit in register ODR results in the corresponding
pin rising or lowering, if this pin is configured in output mode.
- `test_gpio_input_mode()` :
Checks that a input pin set high or low externally results
in the pin rising and lowering.
- `test_pull_up_pull_down()` :
Checks that a floating pin in pull-up/down mode is actually high/down.
- `test_push_pull()` :
Checks that a pin set externally is disconnected when configured in
push-pull output mode, and can't be set externally while in this mode.
- `test_open_drain()` :
Checks that a pin set externally high is disconnected when configured
in open-drain output mode, and can't be set high while in this mode.
- `test_bsrr_brr()` :
Checks that writing to BSRR and BRR has the desired result in ODR.
- `test_clock_enable()` :
Checks that GPIO clock is at the right frequency after enabling it.
Acked-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr>
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
Message-id: 20240305210444.310665-4-ines.varhol@telecom-paris.fr
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tests the following for both P9 and P10:
- I2C master POR status
- I2C master status after immediate reset
Tests the following for powernv10-ranier only:
- Config pca9552 hotplug device pins as inputs then
Read the INPUT0/1 registers to verify all pins are high
- Connected GPIO pin tests of P10 PCA9552 device. Tests
output of pins 0-4 affect input of pins 5-9 respectively.
- PCA9554 GPIO pins test. Tests input and ouput functionality.
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
We deliberately don't include qtests_npcm7xx in qtests_aarch64,
because we already get the coverage of those tests via qtests_arm,
and we don't want to use extra CI minutes testing them twice.
In commit 327b680877 we added it to qtests_aarch64; revert
that change.
Fixes: 327b680877 ("tests/qtest: Creating qtest for GMAC Module")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20240206163043.315535-1-peter.maydell@linaro.org
Added basic qtests for FSI model.
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
[ clg: aspeed-fsi-test.c -> aspeed_fsi-test.c to match other filenames ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
We're still seeing timeouts in qtests that use a TCG payload with TCI
on a slow k8s runner:
https://gitlab.com/qemu-project/qemu/-/jobs/5990992722
So we should bump the timeout of cdrom-test to see whether that
fixes the issue.
Now, cdrom-test, as bios-tables-test, pxe-test and vmgenid-test use
the boot_sector_test() function for running a TCG payload. That
function already uses an internal timeout of 600 seconds with
the remark that the test could be slow with TCI.
Thus from the outer meson test runner side, we should not use less
than 600 seconds as timeout values for these tests. Let's bump them
on the meson side to 610 seconds so that the tests themselves can
run with their internal 600 seconds timeout and have some additional
seconds on top for reporting the outcome.
Message-ID: <20240124084412.465638-1-thuth@redhat.com>
Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The npcm7xx_watchdog_timer-test can take more than 60 seconds in
SPEED=slow mode on a loaded host system.
Bumping to 2 minutes will give more headroom.
Message-ID: <20240112164717.1063954-1-thuth@redhat.com>
Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When running the test in slow mode on a very loaded system with the
arm/aarch64 target and with --enable-debug, it can take longer than
10 minutes to finish the introspection test. Bump the timeout to twelve
minutes to make sure that it also finishes in such situations.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-13-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
On a loaded system with --enable-debug, this test can take longer than
5 minutes. Raising the timeout to 6 minutes gives greater headroom for
such situations.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[thuth: Increase the timeout to 6 minutes for very loaded systems]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-11-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The prom-env-test can take more than 5 minutes in a --enable-debug
build on a loaded system. Bumping to 6 minutes will give more headroom.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[thuth: Bump timeout to 6 minutes instead of 3]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-8-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The pxe-test uses the boot_sector_test() function, and that already
uses a timeout of 600 seconds. So adjust the timeout on the meson
side accordingly.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[thuth: Bump timeout to 600s and adjust commit description]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-7-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The migration test should take between 1 min 30 and 2 mins on reasonably
modern hardware. The test is not especially compute bound, rather its
running time is dominated by the guest RAM size relative to the
bandwidth cap, which forces each iteration to take at least 30 seconds.
None the less under high load conditions with multiple QEMU processes
spawned and competing with other parallel tests, the worst case running
time might be somewhat extended. Bumping the timeout to 8 minutes gives
us good headroom, while still catching stuck tests relatively quickly.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20230717182859.707658-3-berrange@redhat.com>
[thuth: Bump timeout to 8 minutes to make it work on very loaded systems, too]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-3-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This variable is about the host OS, not the target. It is used a lot
more since the Meson conversion, but the original sin dates back to 2003.
Time to fix it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
config_all now lists only accelerators, rename it to indicate its actual
content.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
config_targetos is now empty and can be removed; its use in sourcesets
that do not involve target-specific files can be replaced with an empty
dictionary.
In fact, at this point *all* sourcesets that do not involve
target-specific files are just glorified mutable arrays. Enforce that
they never test for symbols in "when:" by computing the set of files
without "strict: false".
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>