summary refs log tree commit diff stats
path: root/scripts/rust/rustc_args.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-01-09migration/multifd: Cleanup src flushes on condition checkPeter Xu3-7/+47
The src flush condition check is over complicated, and it's getting more out of control if postcopy will be involved. In general, we have two modes to do the sync: legacy or modern ways. Legacy uses per-section flush, modern uses per-round flush. Mapped-ram always uses the modern, which is per-round. Introduce two helpers, which can greatly simplify the code, and hopefully make it readable again. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241206224755.1108686-7-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/multifd: Remove sync processing on postcopyPeter Xu1-8/+0
Multifd never worked with postcopy, at least yet so far. Remove the sync processing there, because it's confusing, and they should never appear. Now if RAM_SAVE_FLAG_MULTIFD_FLUSH is observed, we fail hard instead of trying to invoke multifd code. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20241206224755.1108686-6-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/multifd: Unify RAM_SAVE_FLAG_MULTIFD_FLUSH messagesPeter Xu3-17/+30
RAM_SAVE_FLAG_MULTIFD_FLUSH message should always be correlated to a sync request on src. Unify such message into one place, and conditionally send the message only if necessary. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20241206224755.1108686-5-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/ram: Move RAM_SAVE_FLAG* into ram.hPeter Xu3-28/+28
Firstly, we're going to use the multifd flag soon in multifd code, so ram.c isn't gonna work. Secondly, we have a separate RDMA flag dangling around, which is definitely not obvious. There's one comment that helps, but not too much. Put all RAM save flags altogether, so nothing will get overlooked. Add a section explain why we can't use bits over 0x200. Remove RAM_SAVE_FLAG_FULL as it's already not used in QEMU, as the comment explained. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20241206224755.1108686-4-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/multifd: Allow to sync with sender threads onlyPeter Xu3-10/+37
Teach multifd_send_sync_main() to sync with threads only. We already have such requests, which is when mapped-ram is enabled with multifd. In that case, no SYNC messages will be pushed to the stream when multifd syncs the sender threads because there's no destination threads waiting for that. The whole point of the sync is to make sure all threads finished their jobs. So fundamentally we have a request to do the sync in different ways: - Either to sync the threads only, - Or to sync the threads but also with the destination side. Mapped-ram did it already because of the use_packet check in the sync handler of the sender thread. It works. However it may stop working when e.g. VFIO may start to reuse multifd channels to push device states. In that case VFIO has similar request on "thread-only sync" however we can't check a flag because such sync request can still come from RAM which needs the on-wire notifications. Paving way for that by allowing the multifd_send_sync_main() to specify what kind of sync the caller needs. We can use it for mapped-ram already. No functional change intended. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241206224755.1108686-3-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/multifd: Further remove the SYNC on completePeter Xu1-3/+10
Commit 637280aeb2 ("migration/multifd: Avoid the final FLUSH in complete()") stopped sending the RAM_SAVE_FLAG_MULTIFD_FLUSH flag at ram_save_complete(), because the sync on the destination side is not needed due to the last iteration of find_dirty_block() having already done it. However, that commit overlooked that multifd_ram_flush_and_sync() on the source side is also not needed at ram_save_complete(), for the same reason. Moreover, removing the RAM_SAVE_FLAG_MULTIFD_FLUSH but keeping the multifd_ram_flush_and_sync() means that currently the recv threads will hang when receiving the MULTIFD_FLAG_SYNC message, waiting for the destination sync which only happens when RAM_SAVE_FLAG_MULTIFD_FLUSH is received. Luckily, multifd is still all working fine because recv side cleanup code (mostly multifd_recv_sync_main()) is smart enough to make sure even if recv threads are stuck at SYNC it'll get kicked out. And since this is the completion phase of migration, nothing else will be sent after the SYNCs. This needs to be fixed because in the future VFIO will have data to push after ram_save_complete() and we don't want the recv thread to be stuck in the MULTIFD_FLAG_SYNC message. Remove the unnecessary (and buggy) invocation of multifd_ram_flush_and_sync(). For very old binaries (multifd_flush_after_each_section==true), the flush_and_sync is still needed because each EOS received on destination will enforce all-channel sync once. Stable branches do not need this patch, as no real bug I can think of that will go wrong there.. so not attaching Fixes to be clear on the backport not needed. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20241206224755.1108686-2-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09migration/multifd: Fix compile error caused by page_size usageShameer Kolothum1-1/+1
>From Commit 90fa121c6c07 ("migration/multifd: Inline page_size and page_count") onwards page_size is not part of MutiFD*Params but uses an inline constant instead. However, it missed updating an old usage, causing a compile error. Fixes: 90fa121c6c07 ("migration/multifd: Inline page_size and page_count") Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241203124943.52572-1-shameerali.kolothum.thodi@huawei.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09hw/xen: Check if len is 0 before memcpy()Akihiko Odaki1-0/+4
data->data can be NULL when len is 0. Strictly speaking, the behavior of memcpy() in such a scenario is undefined so UBSan complaints. Satisfy UBSan by checking if len is 0 before memcpy(). Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
2025-01-09hw/i386/pc: Fix level interrupt sharing for Xen event channel GSIDavid Woodhouse3-25/+69
The system GSIs are not designed for sharing. One device might assert a shared interrupt with qemu_set_irq() and another might deassert it, and the level from the first device is lost. This could be solved by refactoring the x86 GSI code to use an OrIrq device, but that still wouldn't be ideal. The best answer would be to have a 'resample' callback which is invoked when the interrupt is acked at the interrupt controller, and causes the devices to re-trigger the interrupt if it should still be pending. This is the model that VFIO in Linux uses, with a 'resampler' eventfd that actually unmasks the interrupt on the hardware device and thus triggers a new interrupt from it if needed. As things stand, QEMU currently doesn't use that VFIO interface correctly, and just bashes on the resampler for every MMIO access to the device "just in case". Which requires unmapping and trapping the MMIO while an interrupt is pending! For the Xen callback GSI, QEMU does something similar — a flag is set which triggers a poll on *every* vmexst to see if the GSI should be deasserted. Proper resampler support would solve all of that, but is a task for later which has already been on the TODO list for a while. Since the Xen event channel GSI support *already* has hooks into the PC gsi_handler() code for routing GSIs to PIRQs, we can use that for a simpler bug fix. So... remember the externally-driven state of the line (from e.g. PCI INTx) and set the logical OR of that with the GSI. As a bonus, we now only need to enable the polling of vcpu_info on vmexit if the Xen callback GSI is the *only* reason the corresponding line is asserted. Closes: https://gitlab.com/qemu-project/qemu/-/issues/2731 Fixes: ddf0fd9ae1fd ("hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com>
2025-01-09hw/intc/loongarch_extioi: Add irq routing support from physical idBibo Mao1-4/+26
The simliar with IPI interrupt controller, physical cpu id is used for irq routing for extioi interrupt controller. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/intc/loongarch_extioi: Remove num-cpu propertyBibo Mao2-2/+0
Since cpu number can be acquired from possible_cpu_arch_ids(), num-cpu property is not necessary. Here remove num-cpu property for object TYPE_LOONGARCH_EXTIOI_COMMON object. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/intc/loongarch_extioi: Get cpu number from possible_cpu_arch_idsBibo Mao3-8/+17
Supported CPU number can be acquired from function possible_cpu_arch_ids(), cpu-num property is not necessary. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09target/loongarch: Only support 64bit pte widthBibo Mao4-15/+26
iFrom LoongArch Reference Manual pte width can be 64bit, 128bit or more. Instead real hardware only supports 64bit pte width. For 12bit pte, there is no detail definition for all 128bit from manual. Here only 64bit pte width is supported for simplicity, will add this in later if real hw support it and there is definition for all the bits from manual. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/loongarch/boot: Support Linux raw boot imageJiaxun Yang1-0/+69
Support booting such image by parsing header as per Linux's specification [1]. This enabled booting vmlinux.efi/vmlinuz.efi shipped by distros without supplying BIOS. [1]: https://docs.kernel.org/arch/loongarch/booting.html Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/core/loader: Use ssize_t for efi zboot unpackerJiaxun Yang3-4/+4
Convert to use sszie_t to represent size internally to avoid large image overflowing the size. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-07tests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplugThomas Huth1-2/+4
When unplugging the CPU, the test tries to check for a successful unplug by changing to the /sys/devices/system/cpu/cpu1 directory to see whether that fails. However, the "cd" could be faster than the unplug operation in the kernel, so there is a race condition and the test sometimes fails here. Fix it by trying to change the directory in a loop until the the CPU has really been unplugged. While we're at it, also add a "cd .." before unplugging to make the console output a little bit less confusing (since the path is echoed in the shell prompt). Reported-by: Stefan Hajnoczi <stefanha@gmail.com> Message-ID: <20250107115245.52755-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07docs/about/deprecated: Remove paragraph about initial deprecation in 2.10Thomas Huth1-6/+0
When we introduced the deprecation rule of keeping deprecated features for two more releases, we had to state that we would not remove features by surprise that had already been marked as deprecated before. Nowadays, this paragraph is not needed anymore, so we can remove it now. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20250103145702.597139-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07Remove the deprecated "-runas" command line optionThomas Huth4-29/+7
It has been marked as deprecated two releases ago, so it should be fine now to remove this command line option. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20250103155411.721759-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x: Remove the "adapter_routes_max_batch" property from the flicThomas Huth3-14/+2
Now that the s390-ccw-virtio-2.8 machine has been removed, we don't need the "adapter_routes_max_batch" property anymore and can remove it. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-11-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine typeThomas Huth1-17/+0
The s390-ccw-virtio-2.8 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-10-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x: Remove the cpu_model_allowed flag and related codeThomas Huth3-19/+3
Now that the last machine type that disabled cpu_model_allowed has been removed, we can also remove the cpu_model_allowed flag itself and all the related conditional code. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-9-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine typeThomas Huth1-15/+0
The s390-ccw-virtio-2.7 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-8-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/css-bridge: Remove the "css_dev_path" propertyThomas Huth2-16/+1
Now that the s390-ccw-virtio-2.6 and older machine types have been removed, the "css_dev_path" property of the css-bridge is also not used anymore and thus can be removed. This way we finally get rid of the problem that has been described in: https://gitlab.com/qemu-project/qemu/-/issues/2213 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/ipl: Remove the "iplbext_migration" propertyThomas Huth2-11/+0
Now that the old machine types that used this property have been removed, we can remove the property and the corresponding code. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-6-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x: Remove the "ri_allowed" switchThomas Huth3-17/+6
Only s390-ccw-virtio-2.6 and older used to set this switch to "off", for newer machine types it is always enabled. Since we removed the old machine types now, we can also remove the switch in the code and assume that it is always enabled now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine typeThomas Huth1-20/+0
The s390-ccw-virtio-2.6 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-4-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-skeys: Remove the "migration-enabled" propertyThomas Huth2-11/+1
This property was only set to "off" by the old s390-ccw-virtio-2.4 machine type which has now been removed. So we can now remove the property and the related code, too. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine typesThomas Huth1-37/+0
They are older than 6 years, so according to our machine support policy, they can be removed now. This removes the requirements for the storage keys "migration-enabled" property which will be removed in the next patch. It also removes the code that sets "max_revision" to 0 for some CCW devices, but the relating code in virtio-ccw.c indicates that 0 could have also been in use for other machines types < 5.1, so further clean-up for code related to "max_revision" won't be done yet (see also commit d55f518248f - "virtio: skip legacy support check on machine types less than 5.1"). Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07tests/tcg/s390x: Use the SLOF libc headers for the multiarch testsIlya Leoshkevich1-1/+2
Compiling the s390x tests on Fedora, which has the s390x cross-compiler installed, fails with: In file included from qemu/tests/tcg/s390x/console.c:8: qemu/tests/tcg/s390x/../../../pc-bios/s390-ccw/sclp.c:11:10: fatal error: string.h: No such file or directory 11 | #include <string.h> This is because Fedora does not have a cross-libc. Since console.c already uses the SLOF libc implementation, add the respective headers to the include path. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241216133819.78583-1-iii@linux.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-06qemu-ga: Optimize freeze-hook script logic of logging errorDehan Meng1-4/+32
Make sure the error log of fsfreeze hooks when freeze/thaw/snapshot could be logged to system logs if the default logfile of qga can't be written or other situations Signed-off-by: Dehan Meng <demeng@redhat.com> Reviewed-by: Yan Vugenfirer <yvugenfi@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Message-ID: <20241225083744.277374-1-demeng@redhat.com> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
2025-01-06qga: implement a 'guest-get-load' commandDaniel P. Berrangé3-0/+58
Provide a way to report the process load average, via a new 'guest-get-load' command. This is only implemented for POSIX platforms providing 'getloadavg'. Example illustrated with qmp-shell: (QEMU) guest-get-load { "return": { "load15m": 1.546875, "load1m": 1.669921875, "load5m": 1.9306640625 } } Windows has no native equivalent API, but it would be possible to simulate it as illustrated here (BSD-3-Clause): https://github.com/giampaolo/psutil/pull/1485 This is left as an exercise for future contributors. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Message-ID: <20241202121927.864335-1-berrange@redhat.com> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
2025-01-02qtest/fw-cfg: remove compiled out codeAni Sinha1-6/+0
Remove code that is already compiled out. This prevents confusion. CC: qemu-trivial@nongnu.org Signed-off-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250101081555.1050736-1-anisinha@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/migration: Re-enable postcopy testsFabiano Rosas1-1/+5
Postcopy tests have been inadvertently disabled since commit 124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to utils"). That commit moved the ufd_version_check() function to another file but failed to make sense of the ifdefs and includes: The <sys/syscall> include was incorrectly dropped. It is needed to pull in <asm/unistd.h> for __NR_userfaultfd. The <sys/ioctl.h> was moved under the wrong ifdef. Fixes: 124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to utils") Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241218192223.10551-2-farosas@suse.de>
2025-01-02tests/migration: Drop arch_[source|target]Peter Xu1-6/+2
Coverity complained about them. These two variables are never used now after commit 832c732c5d ("migration-test: Create arch_opts"), and/or commit 34cc54fb35 ("tests/qtest/migration-test: Use custom asm bios for ppc64"). Resolves: Coverity CID 1568379 Resolves: Coverity CID 1568380 Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20241216161413.1644171-4-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwriteFabiano Rosas1-2/+2
Valgrind complains about: Use of uninitialised value of size 8 & Conditional jump or move depends on uninitialised value(s) both at: at 0x5265931: _itoa_word (_itoa.c:180) by 0x527EEC7: __vfprintf_internal (vfprintf-internal.c:1687) by 0x528C8B0: __vsprintf_internal (iovsprintf.c:96) by 0x526B920: sprintf (sprintf.c:30) by 0x1296C7: qtest_memwrite (libqtest.c:1273) by 0x193C04: send_map (virtio-iommu-test.c:125) by 0x194392: test_attach_detach (virtio-iommu-test.c:214) by 0x17BDE7: run_one_test (qos-test.c:181) by 0x4B0699D: test_case_run (gtestutils.c:2900) by 0x4B0699D: g_test_run_suite_internal (gtestutils.c:2988) by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005) by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005) by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005) Uninitialised value was created by a stack allocation at 0x193AFD: send_map (virtio-iommu-test.c:103) Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20241209204427.17763-5-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/bios-tables-test: Free tables at dump_aml_filesFabiano Rosas1-0/+1
The dump_aml_files() function calls load_expected_aml() to allocate the tables but never frees it. Add the missing call to free_test_data(). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20241209204427.17763-4-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/migration: Initialize buffer in probe_o_direct_supportFabiano Rosas1-0/+1
Valgrind complains about the probe_o_direct_support() function reading from an uninitialized buffer. For probing O_DIRECT support we don't actually need to write to the file, just make sure the pwrite call doesn't reject the write. Still, write zeroes to the buffer to suppress the warning. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20241209204427.17763-3-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/migration: Do proper cleanup in the dirty_limit testFabiano Rosas1-0/+5
The dirty_limit test does two migrations in a row and is leaking the first 'to' instance. Do proper cleanup. Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20241209204427.17763-2-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/qtest/migration: Fix compile errors when CONFIG_UADK is setShameer Kolothum1-54/+0
Removes accidental inclusion of unrelated functions within CONFIG_UADK as this causes compile errors like: error: redefinition of ‘migrate_hook_start_xbzrle’ Fixes: 932f74f3fe6e ("tests/qtest/migration: Split compression tests from migration-test.c") Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241217131046.83844-1-shameerali.kolothum.thodi@huawei.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-02tests/functional/test_arm_quanta_gsj: Fix broken testThomas Huth1-1/+1
ASSET_IMAGE needs to be prefixed with "self." ... this bug apparently went in unnoticed because the test is not run by default. Message-ID: <20250102073403.36328-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sashPhilippe Mathieu-Daudé1-5/+8
Yoshinori said [*] URL references on OSDN were stable, but they appear not to be. Mirror the artifacts on GitHub to avoid failures while testing on CI. [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg686487.html Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Reported-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-ID: <20200630202631.7345-1-f4bug@amsat.org> [huth: Adapt the patch to the new version in the functional framework] Message-ID: <20241229083419.180423-1-huth@tuxfamily.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_ppc64_hv: Update to Alpine 3.21.0Nicholas Piggin1-4/+4
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20241220024617.1968556-5-npiggin@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_ppc64_hv: Update repo managementNicholas Piggin1-3/+4
`setup-apkrepos` can be used to set repos rather than open-coding URLs. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20241220024617.1968556-4-npiggin@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_ppc64_hv: Simplify console handlingNicholas Piggin1-24/+19
Since functional tests have character-based console output parsing, there is no need for strange hacks to work around old line-based. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20241220024617.1968556-3-npiggin@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional: Extract the find_free_ports() function into a helper fileThomas Huth2-28/+64
We'll need this functionality in other functional tests, too, so let's extract it into the qemu_test module. Also add an __enter__ and __exit__ function that can be used for using this functionality in a locked context, so that tests that are running in parallel don't try to compete for the same ports later. Also make sure to only use ports in the "Dynamic Ports" range (see https://www.rfc-editor.org/rfc/rfc6335) and "randomize" the start of the probed range with the PID of the test process to further avoid possible clashes with other competing processes. Message-ID: <20241218131439.255841-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_vnc: Remove the test_no_vnc testThomas Huth1-5/+0
This test matches exactly the first three lines of the following test_no_vnc_change_password test, so there is exactly zero additional test coverage in here. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20241218131439.255841-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional/test_vnc: Do not use a hard-coded VNC portThomas Huth1-2/+2
Two tests here are using the hard-coded VNC port :0 ... if there is already a QEMU or other program running that is using this port, the tests will be failing. Fortunately, QEMU can also auto-detect a free port with the "to=..." parameter, so let's use that for the tests to avoid the problem. Message-ID: <20241218131439.255841-4-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02tests/functional: Convert the vnc testThomas Huth2-5/+8
Nothing thrilling in here, it's just a straight forward conversion. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241218131439.255841-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-02docs: update copyright date to the year 2025Ani Sinha2-2/+2
We are already in January 2025! Update copyright notices. Cc: peter.maydell@linaro.org Cc: qemu-trivial@nongnu.org Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-ID: <20250101080116.1050336-1-anisinha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-31hw/display/qxl: Do not use C99 // commentsHyman Huang1-1/+1
Do not use C99 // comments to fix the checkpatch.pl error Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <7d287eaf00e0b52b600431efd350b15a0b5b3544.1734633496.git.yong.huang@smartx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>