summary refs log tree commit diff stats
path: root/tests/functional/qemu_test/tuxruntest.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-03-12tests/functional/asset: Fail assert fetch when retries are exceededNicholas Piggin1-0/+3
Currently the fetch code does not fail gracefully when retry limit is exceeded, it just falls through the loop with no file, which ends up hitting other errors. Add a check for non-existing file, which indicates the retry limit was exceeded. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20250312130002.945508-2-npiggin@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-03-12docs/system: Fix the information on how to run certain functional testsThomas Huth3-8/+7
The tests have been converted to the functional framework, so we should not talk about Avocado here anymore. Fixes: f7d6b772200 ("tests/functional: Convert BananaPi tests to the functional framework") Fixes: 380f7268b7b ("tests/functional: Convert the OrangePi tests to the functional framework") Fixes: 4c0a2df81c9 ("tests/functional: Convert some tests that download files via fetch_asset()") Message-ID: <20250311160847.388670-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-03-12tests/functional: Bump up arm_replay timeoutPeter Maydell1-0/+1
On my machine the arm_replay test takes over 2 minutes to run in a config with Rust enabled and debug enabled: $ time (cd build/rust ; PYTHONPATH=../../python:../../tests/functional QEMU_TEST_QEMU_BINARY=./qemu-system-arm ./pyvenv/bin/python3 ../../tests/functional/test_arm_replay.py) TAP version 13 ok 1 test_arm_replay.ArmReplay.test_cubieboard ok 2 test_arm_replay.ArmReplay.test_vexpressa9 ok 3 test_arm_replay.ArmReplay.test_virt 1..3 real 2m16.564s user 2m13.461s sys 0m3.523s Bump up the timeout to 4 minutes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20250310102830.3752440-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-03-12tests/functional: Require 'user' netdev for ppc64 e500 testCédric Le Goater1-0/+1
When commit 72cdd672e18c extended the ppc64 e500 test to add network support, it forgot to require the 'user' netdev backend. Fix that. Fixes: 72cdd672e18c ("tests/functional: Replace the ppc64 e500 advent calendar test") Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250308071328.193694-1-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-03-12docs: Rename default-configs to configsGreg Kurz2-13/+13
This was missed at the time. Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise") Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250306174113.427116-1-groug@kaod.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-03-10migration: Prioritize RDMA in ram_save_target_page()Li Zhijian1-4/+5
Address an error in RDMA-based migration by ensuring RDMA is prioritized when saving pages in `ram_save_target_page()`. Previously, the RDMA protocol's page-saving step was placed after other protocols due to a refactoring in commit bc38dc2f5f3. This led to migration failures characterized by unknown control messages and state loading errors destination: (qemu) qemu-system-x86_64: Unknown control message QEMU FILE qemu-system-x86_64: error while loading state section id 1(ram) qemu-system-x86_64: load of migration failed: Operation not permitted source: (qemu) qemu-system-x86_64: RDMA is in an error state waiting migration to abort! qemu-system-x86_64: failed to save SaveStateEntry with id(name): 1(ram): -1 qemu-system-x86_64: rdma migration: recv polling control error! qemu-system-x86_64: warning: Early error. Sending error. qemu-system-x86_64: warning: rdma migration: send polling control error RDMA migration implemented its own protocol/method to send pages to destination side, hand over to RDMA first to prevent pages being saved by other protocol. Fixes: bc38dc2f5f3 ("migration: refactor ram_save_target_page functions") Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Message-ID: <20250305062825.772629-2-lizhijian@fujitsu.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-03-10migration: ram block cpr blockersSteve Sistare4-0/+72
Unlike cpr-reboot mode, cpr-transfer mode cannot save volatile ram blocks in the migration stream file and recreate them later, because the physical memory for the blocks is pinned and registered for vfio. Add a blocker for volatile ram blocks. Also add a blocker for RAM_GUEST_MEMFD. Preserving guest_memfd may be sufficient for CPR, but it has not been tested yet. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <1740667681-257312-1-git-send-email-steven.sistare@oracle.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-03-10migration: Fix UAF for incoming migration on MigrationStatePeter Xu1-2/+38
On the incoming migration side, QEMU uses a coroutine to load all the VM states. Inside, it may reference MigrationState on global states like migration capabilities, parameters, error state, shared mutexes and more. However there's nothing yet to make sure MigrationState won't get destroyed (e.g. after migration_shutdown()). Meanwhile there's also no API available to remove the incoming coroutine in migration_shutdown(), avoiding it to access the freed elements. There's a bug report showing this can happen and crash dest QEMU when migration is cancelled on source. When it happens, the dest main thread is trying to cleanup everything: #0 qemu_aio_coroutine_enter #1 aio_dispatch_handler #2 aio_poll #3 monitor_cleanup #4 qemu_cleanup #5 qemu_default_main Then it found the migration incoming coroutine, schedule it (even after migration_shutdown()), causing crash: #0 __pthread_kill_implementation #1 __pthread_kill_internal #2 __GI_raise #3 __GI_abort #4 __assert_fail_base #5 __assert_fail #6 qemu_mutex_lock_impl #7 qemu_lockable_mutex_lock #8 qemu_lockable_lock #9 qemu_lockable_auto_lock #10 migrate_set_error #11 process_incoming_migration_co #12 coroutine_trampoline To fix it, take a refcount after an incoming setup is properly done when qmp_migrate_incoming() succeeded the 1st time. As it's during a QMP handler which needs BQL, it means the main loop is still alive (without going into cleanups, which also needs BQL). Releasing the refcount now only until the incoming migration coroutine finished or failed. Hence the refcount is valid for both (1) setup phase of incoming ports, mostly IO watches (e.g. qio_channel_add_watch_full()), and (2) the incoming coroutine itself (process_incoming_migration_co()). Note that we can't unref in migration_incoming_state_destroy(), because both qmp_xen_load_devices_state() and load_snapshot() will use it without an incoming migration. Those hold BQL so they're not prone to this issue. PS: I suspect nobody uses Xen's command at all, as it didn't register yank, hence AFAIU the command should crash on master when trying to unregister yank in migration_incoming_state_destroy().. but that's another story. Also note that in some incoming failure cases we may not always unref the MigrationState refcount, which is a trade-off to keep things simple. We could make it accurate, but it can be an overkill. Some examples: - Unlike most of the rest protocols, socket_start_incoming_migration() may create net listener after incoming port setup sucessfully. It means we can't unref in migration_channel_process_incoming() as a generic path because socket protocol might keep using MigrationState. - For either socket or file, multiple IO watches might be created, it means logically each IO watch needs to take one refcount for MigrationState so as to be 100% accurate on ownership of refcount taken. In general, we at least need per-protocol handling to make it accurate, which can be an overkill if we know incoming failed after all. Add a short comment to explain that when taking the refcount in qmp_migrate_incoming(). Bugzilla: https://issues.redhat.com/browse/RHEL-69775 Tested-by: Yan Fu <yafu@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20250220132459.512610-1-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-03-10xen: No need to flush the mapcache for grantsStefano Stabellini1-1/+0
On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular mappings. Since recently we started reusing the mapcache also to keep track of grants mappings. However, there is no need to remove grant mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do that. So remove the function call. Fixes: 9ecdd4bf08 (xen: mapcache: Add support for grant mappings) Cc: qemu-stable@nongnu.org Reported-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech> Message-Id: <20250206194915.3357743-2-edgar.iglesias@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
2025-03-10hw/xen: Add "mode" parameter to xen-block devicesDavid Woodhouse1-0/+2
Block devices don't work in PV Grub (0.9x) if there is no mode specified. It complains: "Error ENOENT when reading the mode" Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20250207143724.30792-2-dwmw2@infradead.org> Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
2025-03-10xen/passthrough: use gsi to map pirq when dom0 is PVHJiqian Chen2-0/+64
In PVH dom0, when passthrough a device to domU, QEMU code xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes the gsi number is got from file /sys/bus/pci/devices/<sbdf>/irq, that is wrong, because irq is not equal with gsi, they are in different spaces, so pirq mapping fails. To solve above problem, use new interface of Xen, xc_pcidev_get_gsi to get gsi and use xc_physdev_map_pirq_gsi to map pirq when dom0 is PVH. Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> Acked-by: Anthony PERARD <anthony@xenproject.org> Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Message-Id: <20241106061418.3655304-1-Jiqian.Chen@amd.com> Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
2025-03-10MAINTAINERS: remove widely sanctioned entitiesAlex Bennée1-4/+3
The following organisations appear on the US sanctions list: Yadro: https://sanctionssearch.ofac.treas.gov/Details.aspx?id=41125 ISPRAS: https://sanctionssearch.ofac.treas.gov/Details.aspx?id=50890 As a result maintainers interacting with such entities would face legal risk in a number of jurisdictions. To reduce the risk of inadvertent non-compliance remove entries from these organisations from the MAINTAINERS file. Mark the pcf8574 system as orphaned until someone volunteers to step up as a maintainer. Add myself as a second reviewer to record/replay so I can help with what odd fixes I can. Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-32-alex.bennee@linaro.org>
2025-03-10plugins/core: make a single build unitAlex Bennée2-13/+2
Trim through the includes and remove everything not needed for the core. Only include tcg-op-common.h to remove the need to TARGET_LONG_BITS and move the build unit into the common set. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-31-alex.bennee@linaro.org>
2025-03-10plugins/api: build only onceAlex Bennée2-13/+1
Now all the softmmu/user-mode stuff has been split out we can build this compilation unit only once. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-30-alex.bennee@linaro.org>
2025-03-10plugins/api: split out time control helpersAlex Bennée3-41/+51
These are only usable in system mode where we control the timer. For user-mode make them NOPs. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-29-alex.bennee@linaro.org>
2025-03-10plugins/api: split out the vaddr/hwaddr helpersAlex Bennée4-71/+99
These only work for system-mode and are NOPs for user-mode. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-28-alex.bennee@linaro.org>
2025-03-10plugins/api: split out binary path/start/end/entry codeAlex Bennée8-44/+115
To move the main api.c to a single build compilation object we need to start splitting out user and system specific code. As we need to grob around host headers we move these particular helpers into the *-user mode directories. The binary/start/end/entry helpers are all NOPs for system mode. While using the plugin-api.c.inc trick means we build for both linux-user and bsd-user the BSD user-mode command line is still missing -plugin. This can be enabled once we have reliable check-tcg tests working for the BSDs. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-27-alex.bennee@linaro.org>
2025-03-10plugins/loader: compile loader only onceAlex Bennée5-12/+57
There is very little in loader that is different between builds save for a tiny user/system mode difference in the plugin_info structure. Create two new files, user and system to hold mode specific helpers and move loader into common_ss. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-26-alex.bennee@linaro.org>
2025-03-10plugins/plugin.h: include queue.hAlex Bennée1-0/+1
Headers should bring in what they need so don't rely on getting queue.h by side effects. This will help with clean-ups in the following patches. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-25-alex.bennee@linaro.org>
2025-03-10plugins/api: clean-up the includesAlex Bennée1-3/+0
Thanks to re-factoring and clean-up work (especially to exec-all) we no longer need such broad headers for the api. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-24-alex.bennee@linaro.org>
2025-03-10include/qemu: plugin-memory.h doesn't need cpu-defs.hAlex Bennée1-1/+0
hwaddr is a fixed size on all builds. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-23-alex.bennee@linaro.org>
2025-03-10plugins/loader: populate target_name with target_name()Alex Bennée1-1/+1
We have a function we can call for this, lets not rely on macros that stop us building once. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-22-alex.bennee@linaro.org>
2025-03-10plugins/api: use qemu_target_page_mask() to get valueAlex Bennée3-3/+4
Requiring TARGET_PAGE_MASK to be defined gets in the way of building this unit once. qemu_target_page_mask() will tell us what it is. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-21-alex.bennee@linaro.org>
2025-03-10tests/functional: add boot error detection for RME testsPierrick Bouvier2-2/+4
It was identified that those tests randomly fail with a synchronous exception at boot (reported by EDK2). While we solve this problem, report failure immediately so tests don't timeout in CI. Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250303185745.2504842-1-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-20-alex.bennee@linaro.org>
2025-03-10gitlab: add a new build_unit job to track build sizeAlex Bennée2-0/+88
We want to reduce the total number of build units in the system to get on our way to a single binary. It will help to have some numbers so lets add a job to gitlab to track our progress. Cc: Pierrick Bouvier <pierrick.bouvier@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-19-alex.bennee@linaro.org>
2025-03-10tests/tcg: Suppress compiler false-positive warning on sha1.cPeter Maydell4-3/+13
GCC versions at least 12 through 15 incorrectly report a warning about code in sha1.c: tests/tcg/multiarch/sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 [-Wstringop-overread] 161 | SHA1Transform(context->state, &data[i]); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a piece of stock library code for doing SHA1 which we've simply copied, rather than writing ourselves. The bug has been reported to upstream GCC (about a different library's use of this code): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106709 For our test case, since this isn't our original code and there isn't actually a bug in it, suppress the incorrect warning rather than trying to modify the code to work around the compiler issue. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2328 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250227141343.1675415-1-peter.maydell@linaro.org> [AJB: -Wno-unknown-warning-option for clang's sake] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-18-alex.bennee@linaro.org>
2025-03-10tests/tcg: enable -fwrapv for test-i386-bmiAlex Bennée1-1/+1
We allow things like: tests/tcg/i386/test-i386-bmi2.c:124:35: warning: shifting a negative signed value is undefined [-Wshift-negative-value] assert(result == (mask & ~(-1 << 30))); in the main code, so allow it for the test. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-17-alex.bennee@linaro.org>
2025-03-10tests/tcg: fix constraints in test-i386-adcoxAlex Bennée1-3/+3
Clang complains: clang -O2 -m64 -mcx16 /home/alex/lsrc/qemu.git/tests/tcg/i386/test-i386-adcox.c -o test-i386-adcox -static /home/alex/lsrc/qemu.git/tests/tcg/i386/test-i386-adcox.c:32:26: error: invalid input constraint '0' in asm : "r" ((REG)-1), "0" (flags), "1" (out_adcx), "2" (out_adox)); ^ /home/alex/lsrc/qemu.git/tests/tcg/i386/test-i386-adcox.c:57:26: error: invalid input constraint '0' in asm : "r" ((REG)-1), "0" (flags), "1" (out_adcx), "2" (out_adox)); ^ 2 errors generated. Pointing out a numbered input constraint can't point to a read/write output [1]. Convert to a read-only input constraint to allow this. [1] https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20101101/036036.html Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-16-alex.bennee@linaro.org>
2025-03-10tests/tcg: add message to _Static_assert in test-avxAlex Bennée1-1/+1
In preparation for enabling clang and avoiding: error: '_Static_assert' with no message is a C2x extension [-Werror,-Wc2x-extensions] let us just add the message to silence the warning. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-15-alex.bennee@linaro.org>
2025-03-10tests/tcg: mark test-vma as a linux-only testAlex Bennée1-0/+0
The main multiarch tests should compile for any POSIX system, however test-vma's usage of MAP_NORESERVE makes it a linux-only test. Simply moving the source file is enough for the build logic to skip on BSD's. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-14-alex.bennee@linaro.org>
2025-03-10tests/vm: bump timeout for shutdownAlex Bennée1-1/+1
On my fairly beefy machine the timeout was triggering leaving a corrupted disk image due to power being pulled before the disk had synced. Triple the timeout to avoid this. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-13-alex.bennee@linaro.org>
2025-03-10libvirt-ci: bump to latest for vulkan-toolsAlex Bennée24-14/+34
The alpine baseline has also been updated in the meantime so we need to address that while we are at it. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-12-alex.bennee@linaro.org>
2025-03-10tests/functional: Allow running TCG plugins tests on non-Linux/BSD hostsPhilippe Mathieu-Daudé2-3/+14
Not all platforms use the '.so' suffix for shared libraries, which is how plugins are built. Use the recently introduced dso_suffix() helper to get the proper host suffix. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2804 Suggested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20250220080215.49165-4-philmd@linaro.org> [AJB: moved plugin_file into testcase.py] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-11-alex.bennee@linaro.org>
2025-03-10tests/functional: Introduce the dso_suffix() helperPhilippe Mathieu-Daudé2-1/+13
Introduce a helper to get the default shared library suffix used on the host. Suggested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20250220080215.49165-3-philmd@linaro.org> [AJB: dropped whitespace cmd.py damage] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-10-alex.bennee@linaro.org>
2025-03-10plugins: add explicit dependency in functional testsPierrick Bouvier4-1/+6
./tests/functional/test_aarch64_tcg_plugins.py needs to have plugin libinsn built. However, it's not listed as a dependency, so meson can't know it needs to be built. Thus, we keep track of all plugins, and add them as an explicit dependency. Fixes: 4c134d07b9e ("tests: add a new set of tests to exercise plugins") Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-9-alex.bennee@linaro.org>
2025-03-10tests/functional: update the aarch64_virg_gpu imagesAlex Bennée1-5/+5
Update to the most recent aarch64_virt_gpu image. The principle differences are: - target a v8.0 baseline CPU - latest vkmark (2025.1) - actually uses the rootfs (previously was initrd) - rootfs includes more testing tools for interactive use See README.md in https://fileserver.linaro.org/s/ce5jXBFinPxtEdx for details about the image creation and the buildroot config. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-8-alex.bennee@linaro.org>
2025-03-10tests/functional: expand tests to cover virglAlex Bennée1-0/+22
Add two more test modes using glmark2-wayland to exercise the OpenGL pass-through modes with virgl. Virgl can run with or without the hostmem blob support. To avoid repeating ourselves too much we make the initial pass a simple --validate pass. We might want to eventually add more directed tests and individual features later on but the glmark/vkmark tests are a good general smoke test for accelerated 3D. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-7-alex.bennee@linaro.org>
2025-03-10tests/functional: skip vulkan tests with nVidiaAlex Bennée1-1/+13
While running the new GPU tests it was noted that the proprietary nVidia driver barfed when run under the sanitiser: 2025-02-20 11:13:08,226: [11:13:07.782] Output 'headless' attempts EOTF mode SDR and colorimetry mode default. 2025-02-20 11:13:08,227: [11:13:07.784] Output 'headless' using color profile: stock sRGB color profile and that's the last thing it outputs. The sanitizer reports that when the framework sends the SIGTERM because of the timeout we get a write to a NULL pointer (but interesting not this time in an atexit callback): UndefinedBehaviorSanitizer:DEADLYSIGNAL ==471863==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7a18ceaafe80 bp 0x000000000000 sp 0x7ffe8e3ff6d0 T471863) ==471863==The signal is caused by a WRITE memory access. ==471863==Hint: address points to the zero page. #0 0x7a18ceaafe80 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x16afe80) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #1 0x7a18ce9e72c0 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15e72c0) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #2 0x7a18ce9f11bb (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x15f11bb) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #3 0x7a18ce6dc9d1 (/lib/x86_64-linux-gnu/libnvidia-eglcore.so.535.183.01+0x12dc9d1) (BuildId: 24b0d0b90369112e3de888a93eb8d7e00304a6db) #4 0x7a18e7d15326 in vrend_renderer_create_fence /usr/src/virglrenderer-1.0.0-1ubuntu2/obj-x86_64-linux-gnu/../src/vrend_renderer.c:10883:26 #5 0x55bfb6621871 in virtio_gpu_virgl_process_cmd The #dri-devel channel confirmed: <digetx> stsquad: nv driver is known to not work with venus, don't use it for testing So lets skip running the test to avoid known failures. As we now use vulkaninfo to probe we also need to handle the case where there is no Vulkan driver configured for the hardware. Reviewed-by: Thomas Huth <thuth@redhat.com> Reported-by: Peter Maydell <peter.maydell@linaro.org> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> [AJB: also skip if vulkaninfo can't find environment] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-6-alex.bennee@linaro.org>
2025-03-10tests/functional: bail early if vkmark hangsAlex Bennée1-3/+5
The message: MESA-VIRTIO: debug: stuck in fence wait with iter at %d Seems to occur more often on debug builds. Rather than waiting for our long timeout to hit we might as well bail as soon as we see the message. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-5-alex.bennee@linaro.org>
2025-03-10tests/functional: ensure we have a GPU device for testsAlex Bennée1-0/+3
It's possible to build QEMU without support for the GL enabled GPU devices and we can catch that earlier with an explicit check. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-4-alex.bennee@linaro.org>
2025-03-10tests/functional: factor out common code in gpu testAlex Bennée1-17/+21
In preparation for handling more tests split out the common machine setup details from the test specific stuff and add a helper for launching the weston test. Instead of searching for "vkmark score" we set a custom PS1 and wait for a successful completion. This ensures we capture the score in the console log which otherwise wouldn't log anything. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-3-alex.bennee@linaro.org>
2025-03-10tests/functional: move aarch64 GPU test into own fileAlex Bennée4-72/+98
I want to expand the number of tests to cover a wide range of configurations. That starts with splitting off from the normal virt test from which it doesn't really share much code. We can also reduce the timeout of the original virt test now it is now longer burdened with testing the GPU. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250304222439.2035603-2-alex.bennee@linaro.org>
2025-03-10tap-linux: Open ipvtap and macvtapAkihiko Odaki1-3/+14
ipvtap and macvtap create a file for each interface unlike tuntap, which creates one file shared by all interfaces. Try to open a file dedicated to the interface first for ipvtap and macvtap. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-03-10Revert "hw/net/net_tx_pkt: Fix overrun in update_sctp_checksum()"Akihiko Odaki1-4/+0
This reverts commit 83ddb3dbba2ee0f1767442ae6ee665058aeb1093. The added check is no longer necessary due to a change of iov_from_buf(). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-03-10util/iov: Do not assert offset is in iovAkihiko Odaki2-7/+3
iov_from_buf(), iov_to_buf(), iov_memset(), and iov_copy() asserts that the given offset fits in the iov while tolerating the specified number of bytes to operate with to be greater than the size of iov. This is inconsistent so remove the assertions. Asserting the offset fits in the iov makes sense if it is expected that there are other operations that process the content before the offset and the content is processed in order. Under this expectation, the offset should point to the end of bytes that are previously processed and fit in the iov. However, this expectation depends on the details of the caller, and did not hold true at least one case and required code to check iov_size(), which is added with commit 83ddb3dbba2e ("hw/net/net_tx_pkt: Fix overrun in update_sctp_checksum()"). Adding such a check is inefficient and error-prone. These functions already tolerate the specified number of bytes to operate with to be greater than the size of iov to avoid such checks so remove the assertions to tolerate invalid offset as well. They return the number of bytes they operated with so their callers can still check the returned value to ensure there are sufficient space at the given offset. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-03-10net: move backend cleanup to NIC cleanupEugenio Pérez2-14/+27
Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if peer nic is present") effectively delayed the backend cleanup, allowing the frontend or the guest to access it resources as long as the frontend is still visible to the guest. However it does not clean up the resources until the qemu process is over. This causes an effective leak if the device is deleted with device_del, as there is no way to close the vdpa device. This makes impossible to re-add that device to this or other QEMU instances until the first instance of QEMU is finished. Move the cleanup from qemu_cleanup to the NIC deletion and to net_cleanup. Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if peer nic is present") Reported-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-03-10net: parameterize the removing client from nc listEugenio Pérez1-5/+8
This change is used in later commits so we can avoid the removal of the netclient if it is delayed. No functional change intended. Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-03-09MAINTAINERS: Consolidate core exec/vCPU handling sectionPhilippe Mathieu-Daudé1-7/+7
Some common cpu/exec files are listed under the 'TCG CPUs' section. Move them to the generic 'Overall Guest CPU Cores' one where they belong. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250308134938.77267-1-philmd@linaro.org>
2025-03-09cpus: Remove CPUClass::has_work() handlerPhilippe Mathieu-Daudé5-15/+16
All handlers have been converted to SysemuCPUOps::has_work(). Remove CPUClass::has_work along with cpu_common_has_work() and simplify cpu_has_work(), making SysemuCPUOps::has_work handler mandatory. Note, since cpu-common.c is in meson's common_ss[] source set, we must define cpu_exec_class_post_init() in cpu-target.c (which is in the specific_ss[] source set) to have CONFIG_USER_ONLY defined. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250125170125.32855-25-philmd@linaro.org>
2025-03-09target/xtensa: Move has_work() from CPUClass to SysemuCPUOpsPhilippe Mathieu-Daudé1-7/+5
Move has_work() from CPUClass to SysemuCPUOps, simplifying xtensa_cpu_has_work() by directly using CPU env. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250125170125.32855-24-philmd@linaro.org>