summary refs log tree commit diff stats
path: root/rust/qemu-api/src/assertions.rs (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-03-11hw/virtio/virtio-mem: Remove CONFIG_DEVICES includePhilippe Mathieu-Daudé1-4/+2
Rather than checking ACPI availability at compile time by checking the CONFIG_ACPI definition from CONFIG_DEVICES, check at runtime via acpi_builtin(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20250307223949.54040-5-philmd@linaro.org>
2025-03-11hw/i386/fw_cfg: Check ACPI availability with acpi_builtin()Philippe Mathieu-Daudé2-4/+7
Define acpi_tables / acpi_tables_len stubs, then replace the compile-time CONFIG_ACPI check in fw_cfg.c by a runtime one. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20250307223949.54040-4-philmd@linaro.org>
2025-03-11hw/acpi: Introduce acpi_builtin() helperPhilippe Mathieu-Daudé3-0/+13
acpi_builtin() can be used to check at runtime whether the ACPI subsystem is built in a qemu-system binary. Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250307223949.54040-3-philmd@linaro.org>
2025-03-11system: Replace arch_type global by qemu_arch_available() helperPhilippe Mathieu-Daudé5-8/+11
qemu_arch_available() is a bit simpler to understand while reviewing than the undocumented arch_type variable. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250305005225.95051-5-philmd@linaro.org>
2025-03-11system: Extract target-specific globals to their own compilation unitPhilippe Mathieu-Daudé3-14/+25
We shouldn't use target specific globals for machine properties. These ones could be desugarized, as explained in [*]. While certainly doable, not trivial nor my priority for now. Just move them to a different file to clarify they are *globals*, like the generic globals residing in system/globals.c. Since arch_init.c was introduced using the MIT license (see commit ad96090a01d), retain the same license for the new globals-target.c file. [*] https://lore.kernel.org/qemu-devel/e514d6db-781d-4afe-b057-9046c70044dc@redhat.com/ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20250305005225.95051-2-philmd@linaro.org>
2025-03-11hw/xen/hvm: Fix Aarch64 typoPhilippe Mathieu-Daudé1-1/+1
There is no TARGET_ARM_64 definition. Luckily enough, when TARGET_AARCH64 is defined, TARGET_ARM also is. Fixes: 733766cd373 ("hw/arm: introduce xenpvh machine") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250305153929.43687-2-philmd@linaro.org>
2025-03-11hw/net/smc91c111: Don't allow data register access to overrun bufferPeter Maydell1-12/+53
For accesses to the 91c111 data register, the address within the packet's data frame is determined by a combination of the pointer register and the offset used to access the data register, so that you can access data at effectively wider than byte width. The pointer register's pointer field is 11 bits wide, which is exactly the size to index a 2048-byte data frame. We weren't quite getting the logic right for ensuring that we end up with a pointer value to use in the s->data[][] array that isn't out of bounds: * we correctly mask when getting the initial pointer value * for the "autoincrement the pointer register" case, we correctly mask after adding 1 so that the pointer register wraps back around at the 2048 byte mark * but for the non-autoincrement case where we have to add the low 2 bits of the data register offset, we don't account for the possibility that the pointer register is 0x7ff and the addition should wrap Fix this bug by factoring out the "get the p value to use as an array index" into a function, making it use FIELD macro names rather than hard-coded constants, and having a utility function that does "add a value and wrap it" that we can use both for the "autoincrement" and "add the offset bits" codepaths. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250228191652.1957208-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-03-11hw/net/smc91c111: Use MAX_PACKET_SIZE instead of magic numbersPeter Maydell1-3/+5
Now we have a constant for the maximum packet size, we can use it to replace various hardcoded 2048 values. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250228174802.1945417-4-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-03-11hw/net/smc91c111: Sanitize packet length on txPeter Maydell1-5/+29
When the smc91c111 transmits a packet, it must read a control byte which is at the end of the data area and CRC. However, we don't sanitize the length field in the packet buffer, so if the guest sets the length field to something large we will try to read past the end of the packet data buffer when we access the control byte. As usual, the datasheet says nothing about the behaviour of the hardware if the guest misprograms it in this way. It says only that the maximum valid length is 2048 bytes. We choose to log the guest error and silently drop the packet. This requires us to factor out the "mark the tx packet as complete" logic, so we can call it for this "drop packet" case as well as at the end of the loop when we send a valid packet. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250228174802.1945417-3-peter.maydell@linaro.org> [PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-03-11hw/net/smc91c111: Sanitize packet numbersPeter Maydell1-0/+45
The smc91c111 uses packet numbers as an index into its internal s->data[][] array. Valid packet numbers are between 0 and 3, but the code does not generally check this, and there are various places where the guest can hand us an arbitrary packet number and cause an out-of-bounds access to the data array. Add validation of packet numbers. The datasheet is not very helpful about how guest errors like this should be handled: it says nothing on the subject, and none of the documented error conditions are relevant. We choose to log the situation with LOG_GUEST_ERROR and silently ignore the attempted operation. In the places where we are about to access the data[][] array using a packet number and we know the number is valid because we got it from somewhere that has already validated, we add an assert() to document that belief. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250228174802.1945417-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-03-11hw/rtc: Add Ricoh RS5C372 RTC emulationBernhard Beschow7-0/+292
The implementation just allows Linux to determine date and time. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20250223114708.1780-19-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-03-11hw/sd/sdhci: Set reset value of interrupt registersBALATON Zoltan3-0/+6
The interrupt enable registers are not reset to 0 on Freescale eSDHC but some bits are enabled on reset. At least some U-Boot versions seem to expect this and not initialise these registers before expecting interrupts. Use existing vendor property for Freescale eSDHC and set the reset value of the interrupt registers to match Freescale documentation. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-ID: <20250210160329.DDA7F4E600E@zero.eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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>