https://github.com/qemu/qemu

sort by:
Revision Author Date Message Commit Date
f48ba9b Update version for 7.2.12 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 08 June 2024, 21:23:52 UTC
6f62fc9 target/loongarch: fix a wrong print in cpu dump description: loongarch_cpu_dump_state() want to dump all loongarch cpu state registers, but there is a tiny typographical error when printing "PRCFG2". Cc: qemu-stable@nongnu.org Signed-off-by: lanyanzhi <lanyanzhi22b@ict.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20240604073831.666690-1-lanyanzhi22b@ict.ac.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> (cherry picked from commit 78f932ea1f7b3b9b0ac628dc2a91281318fe51fa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 07 June 2024, 05:10:49 UTC
61687b3 ui/sdl2: Allow host to power down screen By default, SDL disables the screen saver which prevents the host from powering down the screen even if the screen is locked. This results in draining the battery needlessly when the host isn't connected to a wall charger. Fix that by enabling the screen saver. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20240512095945.1879-1-shentey@gmail.com> (cherry picked from commit 2e701e6785cd8cc048c608751c6e4f6253c67ab6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 06 June 2024, 11:20:13 UTC
082940a target/i386: fix SSE and SSE2 feature check Features check of CPUID_SSE and CPUID_SSE2 should use cpuid_features, rather than cpuid_ext_features. Signed-off-by: Xinyu Li <lixinyu20s@ict.ac.cn> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240602100904.2137939-1-lixinyu20s@ict.ac.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit da7c95920d027dbb00c6879c1da0216b19509191) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 06 June 2024, 11:17:00 UTC
9aca1a8 target/i386: fix xsave.flat from kvm-unit-tests xsave.flat checks that "executing the XSETBV instruction causes a general- protection fault (#GP) if ECX = 0 and EAX[2:1] has the value 10b". QEMU allows that option, so the test fails. Add the condition. Cc: qemu-stable@nongnu.org Fixes: 892544317fe ("target/i386: implement XSAVE and XRSTOR of AVX registers", 2022-10-18) Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 7604bbc2d87d153e65e38cf2d671a5a9a35917b1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 06 June 2024, 11:14:19 UTC
81ca6c2 disas/riscv: Decode all of the pmpcfg and pmpaddr CSRs Previously we only listed a single pmpcfg CSR and the first 16 pmpaddr CSRs. This patch fixes this to list all 16 pmpcfg and all 64 pmpaddr CSRs are part of the disassembly. Reported-by: Eric DeVolder <eric_devolder@yahoo.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Fixes: ea10325917 ("RISC-V Disassembler") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240514051615.330979-1-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 915758c537b5fe09575291f4acd87e2d377a93de) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 June 2024, 10:07:40 UTC
b73e371 hw/intc/riscv_aplic: APLICs should add child earlier than realize Since only root APLICs can have hw IRQ lines, aplic->parent should be initialized first. Fixes: e8f79343cf ("hw/intc: Add RISC-V AIA APLIC device emulation") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: yang.zhang <yang.zhang@hexintek.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240409014445.278-1-gaoshanliukou@163.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c76b121840c6ca79dc6305a5f4bcf17c72217d9c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 June 2024, 10:00:20 UTC
e08fbea target/arm: Disable SVE extensions when SVE is disabled Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2304 Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-id: 20240526204551.553282-1-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit daf9748ac002ec35258e5986b6257961fd04b565) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 June 2024, 04:20:31 UTC
eed21e9 hw/intc/arm_gic: Fix handling of NS view of GICC_APR<n> In gic_cpu_read() and gic_cpu_write(), we delegate the handling of reading and writing the Non-Secure view of the GICC_APR<n> registers to functions gic_apr_ns_view() and gic_apr_write_ns_view(). Unfortunately we got the order of the arguments wrong, swapping the CPU number and the register number (which the compiler doesn't catch because they're both integers). Most guests probably didn't notice this bug because directly accessing the APR registers is typically something only done by firmware when it is doing state save for going into a sleep mode. Correct the mismatched call arguments. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: 51fd06e0ee ("hw/intc/arm_gic: Fix handling of GICC_APR<n>, GICC_NSAPR<n> registers") Signed-off-by: Andrey Shumilin <shum.sdl@nppct.ru> [PMM: Rewrote commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée<alex.bennee@linaro.org> (cherry picked from commit daafa78b297291fea36fb4daeed526705fa7c035) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 30 May 2024, 14:13:32 UTC
c6fe98f hvf: arm: Fix encodings for ID_AA64PFR1_EL1 and debug System registers We wrongly encoded ID_AA64PFR1_EL1 using {3,0,0,4,2} in hvf_sreg_match[] so we fail to get the expected ARMCPRegInfo from cp_regs hash table with the wrong key. Fix it with the correct encoding {3,0,0,4,1}. With that fixed, the Linux guest can properly detect FEAT_SSBS2 on my M1 HW. All DBG{B,W}{V,C}R_EL1 registers are also wrongly encoded with op0 == 14. It happens to work because HVF_SYSREG(CRn, CRm, 14, op1, op2) equals to HVF_SYSREG(CRn, CRm, 2, op1, op2), by definition. But we shouldn't rely on it. Cc: qemu-stable@nongnu.org Fixes: a1477da3ddeb ("hvf: Add Apple Silicon support") Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Reviewed-by: Alexander Graf <agraf@csgraf.de> Message-id: 20240503153453.54389-1-zenghui.yu@linux.dev Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 19ed42e8adc87a3c739f61608b66a046bb9237e2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 30 May 2024, 14:11:59 UTC
07f6860 gitlab: Update msys2-64bit runner tags Gitlab has deprecated and removed support for windows-1809 and shared-windows. Update to saas-windows-medium-amd64 per https://about.gitlab.com/blog/2024/01/22/windows-2022-support-for-gitlab-saas-runners/ Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-Id: <20240507175356.281618-1-richard.henderson@linaro.org> (cherry picked from commit 36fa7c686e9eac490002ffc439c4affaa352c17c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 07:53:21 UTC
f417712 target/i386: no single-step exception after MOV or POP SS Intel SDM 18.3.1.4 "If an occurrence of the MOV or POP instruction loads the SS register executes with EFLAGS.TF = 1, no single-step debug exception occurs following the MOV or POP instruction." Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit f0f0136abba688a6516647a79cc91e03fad6d5d7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup for v8.1.0-1189-gad75a51e84af "tcg: Rename cpu_env to tcg_env") 27 May 2024, 04:30:35 UTC
9abcd96 target/i386: disable jmp_opt if EFLAGS.RF is 1 If EFLAGS.RF is 1, special processing in gen_eob_worker() is needed and therefore goto_tb cannot be used. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 8225bff7c5db504f50e54ef66b079854635dba70) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 04:30:35 UTC
ddc13a3 target-i386: hyper-v: Correct kvm_hv_handle_exit return value This bug fix addresses the incorrect return value of kvm_hv_handle_exit for KVM_EXIT_HYPERV_SYNIC, which should be EXCP_INTERRUPT. Handling of KVM_EXIT_HYPERV_SYNIC in QEMU needs to be synchronous. This means that async_synic_update should run in the current QEMU vCPU thread before returning to KVM, returning EXCP_INTERRUPT to guarantee this. Returning 0 can cause async_synic_update to run asynchronously. One problem (kvm-unit-tests's hyperv_synic test fails with timeout error) caused by this bug: When a guest VM writes to the HV_X64_MSR_SCONTROL MSR to enable Hyper-V SynIC, a VM exit is triggered and processed by the kvm_hv_handle_exit function of the QEMU vCPU. This function then calls the async_synic_update function to set synic->sctl_enabled to true. A true value of synic->sctl_enabled is required before creating SINT routes using the hyperv_sint_route_new() function. If kvm_hv_handle_exit returns 0 for KVM_EXIT_HYPERV_SYNIC, the current QEMU vCPU thread may return to KVM and enter the guest VM before running async_synic_update. In such case, the hyperv_synic test’s subsequent call to synic_ctl(HV_TEST_DEV_SINT_ROUTE_CREATE, ...) immediately after writing to HV_X64_MSR_SCONTROL can cause QEMU’s hyperv_sint_route_new() function to return prematurely (because synic->sctl_enabled is false). If the SINT route is not created successfully, the SINT interrupt will not be fired, resulting in a timeout error in the hyperv_synic test. Fixes: 267e071bd6d6 (“hyperv: make overlay pages for SynIC”) Suggested-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Dongsheng Zhang <dongsheng.x.zhang@intel.com> Message-ID: <20240521200114.11588-1-dongsheng.x.zhang@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 84d4b72854869821eb89813c195927fdd3078c12) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 04:30:35 UTC
5ec422a ui/gtk: Check if fence_fd is equal to or greater than 0 'fence_fd' needs to be validated always before being referenced And the passing condition should include '== 0' as 0 is a valid value for the file descriptor. Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Message-Id: <20240508175403.3399895-2-dongwon.kim@intel.com> (cherry picked from commit e4e62514e3cc2fc9dbae44af8b80f61c730beab4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 04:30:35 UTC
659835d ui/gtk: Fix mouse/motion event scaling issue with GTK display backend Remove gtk_widget_get_scale_factor() usage from the calculation of the motion events in the GTK backend to make it work correctly on environments that have `gtk_widget_get_scale_factor() != 1`. This scale factor usage had been introduced in the commit f14aab420c and at that time the window size was used for calculating the things and it was working correctly. However, in the commit 2f31663ed4 the logic switched to use the widget size instead of window size and because of the change the usage of scale factor becomes invalid (since widgets use `vc->gfx.scale_{x, y}` for scaling). Tested on Crostini on ChromeOS (15823.51.0) with an external display. Fixes: 2f31663ed4 ("ui/gtk: use widget size for cursor motion event") Fixes: f14aab420c ("ui: fix incorrect pointer position on highdpi with gtk") (f14aab420c is 95c9059e66 in stable-7.2) Signed-off-by: hikalium <hikalium@hikalium.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20240512111435.30121-3-hikalium@hikalium.com> (cherry picked from commit 37e91415018db3656b46cdea8f9e4d47b3ff130d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 04:30:35 UTC
e6000bd target/i386: rdpkru/wrpkru are no-prefix instructions Reject 0x66/0xf3/0xf2 in front of them. Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 40a3ec7b5ffde500789d016660a171057d6b467c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 May 2024, 04:30:35 UTC
76b96c0 target/i386: fix operand size for DATA16 REX.W POPCNT According to the manual, 32-bit vs 64-bit is governed by REX.W and REX ignores the 0x66 prefix. This can be confirmed with this program: #include <stdio.h> int main() { int x = 0x12340000; int y; asm("popcntl %1, %0" : "=r" (y) : "r" (x)); printf("%x\n", y); asm("mov $-1, %0; .byte 0x66; popcntl %1, %0" : "+r" (y) : "r" (x)); printf("%x\n", y); asm("mov $-1, %0; .byte 0x66; popcntq %q1, %q0" : "+r" (y) : "r" (x)); printf("%x\n", y); } which prints 5/ffff0000/5 on real hardware and 5/ffff0000/ffff0000 on QEMU. Cc: qemu-stable@nongnu.org Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 41c685dc59bb611096f3bb6a663cfa82e4cba97b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop removal of mo_64_32() helper function in target/i386/tcg/translate.c due to missing-in-7.2 v9.0.0-542-gaef4f4affde2 "target/i386: remove now-converted opcodes from old decoder" which removed other user of it) 27 May 2024, 04:28:12 UTC
2b8be9c hw/remote/vfio-user: Fix config space access byte order PCI config space is little-endian, so on a big-endian host we need to perform byte swaps for values as they are passed to and received from the generic PCI config space access machinery. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Mattias Nissler <mnissler@rivosinc.com> Message-ID: <20240507094210.300566-6-mnissler@rivosinc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit e6578f1f68a0e90789a841ada532c3e494c9a04c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 May 2024, 10:20:20 UTC
41e052f target/i386: Give IRQs a chance when resetting HF_INHIBIT_IRQ_MASK When emulated with QEMU, interrupts will never come in the following loop. However, if the NOP instruction is uncommented, interrupts will fire as normal. loop: cli call do_sti jmp loop do_sti: sti # nop ret This behavior is different from that of a real processor. For example, if KVM is enabled, interrupts will always fire regardless of whether the NOP instruction is commented or not. Also, the Intel Software Developer Manual states that after the STI instruction is executed, the interrupt inhibit should end as soon as the next instruction (e.g., the RET instruction if the NOP instruction is commented) is executed. This problem is caused because the previous code may choose not to end the TB even if the HF_INHIBIT_IRQ_MASK has just been reset (e.g., in the case where the STI instruction is immediately followed by the RET instruction), so that IRQs may not have a change to trigger. This commit fixes the problem by always terminating the current TB to give IRQs a chance to trigger when HF_INHIBIT_IRQ_MASK is reset. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Message-ID: <20240415064518.4951-4-lrh2000@pku.edu.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 6a5a63f74ba5c5355b7a8468d3d814bfffe928fb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup due to missing-in-7.2 v8.1.0-1189-gad75a51e84 "tcg: Rename cpu_env to tcg_env") 09 May 2024, 13:37:00 UTC
2e3e513 hw/arm/npcm7xx: Store derivative OTP fuse key in little endian Use little endian for derivative OTP fuse key. Cc: qemu-stable@nongnu.org Fixes: c752bb079b ("hw/nvram: NPCM7xx OTP device model") Suggested-by: Avi Fishman <Avi.Fishman@nuvoton.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240422125813.1403-1-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit eb656a60fd93262b1e519b3162888bf261df7f68) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 02 May 2024, 10:17:18 UTC
a004dfa hw/dmax/xlnx_dpdma: fix handling of address_extension descriptor fields The DMA descriptor structures for this device have a set of "address extension" fields which extend the 32 bit source addresses with an extra 16 bits to give a 48 bit address: https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field However, we misimplemented this address extension in several ways: * we only extracted 12 bits of the extension fields, not 16 * we didn't shift the extension field up far enough * we accidentally did the shift as 32-bit arithmetic, which meant that we would have an overflow instead of setting bits [47:32] of the resulting 64-bit address Add a type cast and use extract64() instead of extract32() to avoid integer overflow on addition. Fix bit fields extraction according to documentation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: d3c6369a96 ("introduce xlnx-dpdma") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Message-id: 20240428181131.23801-1-adiupina@astralinux.ru [PMM: adjusted commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4b00855f0ee2e2eee8fd2500ffef27c108be6dc3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 02 May 2024, 10:16:29 UTC
9a005e3 .gitlab-ci.d/cirrus.yml: Shorten the runtime of the macOS and FreeBSD jobs Cirrus-CI introduced limitations to the free CI minutes. To avoid that we are consuming them too fast, let's drop the usual targets that are not that important since they are either a subset of another target (like i386 or ppc being a subset of x86_64 or ppc64 respectively), or since there is still a similar target with the opposite endianness (like xtensa/xtensael, microblaze/microblazeel etc.). Message-ID: <20240429100113.53357-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit a88a04906b966ffdcda23a5a456abe10aa8c826e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 May 2024, 08:10:44 UTC
e00c9b4 tests/avocado: update sunxi kernel from armbian to 6.6.16 The Linux kernel 5.10.16 binary for sunxi has been removed from apt.armbian.com. This means that the avocado tests for these machines will be skipped (status CANCEL) if the old binary isn't present in the avocado cache. Update to 6.6.16, in the same way we did in commit e384db41d8661 when we moved to 5.10.16 in 2021. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2284 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20240415151845.1564201-1-peter.maydell@linaro.org (cherry picked from commit dcc5c018c7e6acddf81951bcbdf1019b9ab45f56) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop changes for tests which does not exists in 7.2) 01 May 2024, 06:06:23 UTC
39a0961 backends/cryptodev-builtin: Fix local_error leaks It seems that this error does not need to be propagated to the upper, directly output the error to avoid the leaks Closes: https://gitlab.com/qemu-project/qemu/-/issues/2283 Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode") Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: zhenwei pi <pizhenwei@bytedance.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 06479dbf3d7d245572c4b3016e5a1d923ff04d66) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 30 April 2024, 17:10:14 UTC
f7b46e8 nbd/server: Mark negotiation functions as coroutine_fn nbd_negotiate() is already marked coroutine_fn. And given the fix in the previous patch to have nbd_negotiate_handle_starttls not create and wait on a g_main_loop (as that would violate coroutine constraints), it is worth marking the rest of the related static functions reachable only during option negotiation as also being coroutine_fn. Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240408160214.1200629-6-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> [eblake: drop one spurious coroutine_fn marking] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 4fa333e08dd96395a99ea8dd9e4c73a29dd23344) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixups in nbd/server.c for v8.1.0-1366-gfd358d83901d "nbd/server: Refactor list of negotiated meta contexts") 28 April 2024, 12:16:47 UTC
a0823c2 nbd/server: do not poll within a coroutine context Coroutines are not supposed to block. Instead, they should yield. The client performs TLS upgrade outside of an AIOContext, during synchronous handshake; this still requires g_main_loop. But the server responds to TLS upgrade inside a coroutine, so a nested g_main_loop is wrong. Since the two callbacks no longer share more than the setting of data.complete and data.error, it's just as easy to use static helpers instead of trying to share a common code path. It is also possible to add assertions that no other code is interfering with the eventual path to qio reaching the callback, whether or not it required a yield or main loop. Fixes: f95910f ("nbd: implement TLS support in the protocol negotiation") Signed-off-by: Zhu Yangyang <zhuyangyang14@huawei.com> [eblake: move callbacks to their use point, add assertions] Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240408160214.1200629-5-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> (cherry picked from commit ae6d91a7e9b77abb029ed3fa9fad461422286942) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 28 April 2024, 12:13:17 UTC
51cc876 linux-user: do_setsockopt: fix SOL_ALG.ALG_SET_KEY This setsockopt accepts zero-lengh optlen (current qemu implementation does not allow this). Also, there's no need to make a copy of the key, it is enough to use lock_user() (which accepts zero length already). Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2197 Fixes: f31dddd2fc "linux-user: Add support for setsockopt() option SOL_ALG" Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <20240331100737.2724186-2-mjt@tls.msk.ru> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 04f6fb897a5aeb3e356a7b889869c9962f9c16c7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 25 April 2024, 19:19:25 UTC
6ea6863 gitlab/opensbi: Move to docker:stable The OpenSBI build has been using docker:19.03.1, which appears to be old enough that v2 of the manifest is no longer supported. Something has started serving us those manifests, resulting in errors along the lines of $ docker build --cache-from $IMAGE_TAG --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $IMAGE_TAG .gitlab-ci.d/opensbi Step 1/7 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not 'application/vnd.oci.image.manifest.v1+json' This moves to docker:stable, as was suggested by the template. It also adds the python3 package via apt, as OpenSBI requires that to build. Reviewed-by: Bin Meng <bmeng@tinylab.org> Message-ID: <20230303202448.11911-2-palmer@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> (cherry picked from commit 7bc1286b81d4e8380b3083beed1771c67ce87af3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 24 April 2024, 09:30:47 UTC
861fca8 gitlab-ci: Remove job building EDK2 firmware binaries When we introduced this Gitlab-CI job in commit 71920809ce ("gitlab-ci.yml: Add jobs to build EDK2 firmware binaries"), the naive plan was to have reproducible binaries by downloading what this job would build, testing it and eventually committing it. With retrospective, nothing happened 3 years later and this job is just bitrotting: Step 1/3 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not 'application/vnd.oci.image.manifest.v1+json' Remove this job to avoid wasting maintenance and CI ressources. Reported-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230310133247.39268-1-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 690ceb71936f9037f6e11580709e26b62d83c17c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 24 April 2024, 09:29:57 UTC
c6fe0f3 Update version for 7.2.11 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 24 April 2024, 03:02:50 UTC
ab4a60c ppc/spapr: Initialize max_cpus limit to SPAPR_IRQ_NR_IPIS. Initialize the machine specific max_cpus limit as per the maximum range of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not free error due to XIVE/XICS limitation and keeping beyond 8192 will hit assert in tcg_region_init or spapr_xive_claim_irq. Logs: Without patch fix: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097 qemu-system-ppc64: IRQ 4096 is not free [root@host build]# On LPAR: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=8193 ** ERROR:../tcg/region.c:774:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Bail out! ERROR:../tcg/region.c:774:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Aborted (core dumped) [root@host build]# On x86: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=8193 qemu-system-ppc64: ../hw/intc/spapr_xive.c:596: spapr_xive_claim_irq: Assertion `lisn < xive->nr_irqs' failed. Aborted (core dumped) [root@host build]# With patch fix: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097 qemu-system-ppc64: Invalid SMP CPUs 4097. The max CPUs supported by machine 'pseries-8.2' is 4096 [root@host build]# Reported-by: Kowshik Jois <kowsjois@linux.ibm.com> Tested-by: Kowshik Jois <kowsjois@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit c4f91d7b7be76c47015521ab0109c6e998a369b0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 16 April 2024, 18:16:12 UTC
3f481e3 ppc/spapr: Introduce SPAPR_IRQ_NR_IPIS to refer IRQ range for CPU IPIs. spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to the range of CPU IPIs during initialization of nr-irqs property. It is more appropriate to have its own define which can be further reused as appropriate for correct interpretation. Suggested-by: Cedric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Kowshik Jois <kowsjois@linux.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit 2df5c1f5b014126595a26c6797089d284a3b211c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 16 April 2024, 18:16:09 UTC
4741ae6 target/sh4: add missing CHECK_NOT_DELAY_SLOT CHECK_NOT_DELAY_SLOT is correctly applied to the branch-related instructions, but not to the PC-relative mov* instructions. I verified the existence of an illegal slot exception on a SH7091 when any of these instructions are attempted inside a delay slot. This also matches the behavior described in the SH-4 ISA manual. Signed-off-by: Zack Buhman <zack@buhman.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240407150705.5965-1-zack@buhman.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewd-by: Yoshinori Sato <ysato@users.sourceforge.jp> (cherry picked from commit b754cb2dcde26a7bc8a9d17bb6900a0ac0dd38e2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial context (whitespace before comments) fixup) 10 April 2024, 17:40:02 UTC
2429cb7 hw/sd/sdhci: Do not update TRNMOD when Command Inhibit (DAT) is set Per "SD Host Controller Standard Specification Version 3.00": * 2.2.5 Transfer Mode Register (Offset 00Ch) Writes to this register shall be ignored when the Command Inhibit (DAT) in the Present State register is 1. Do not update the TRNMOD register when Command Inhibit (DAT) bit is set to avoid the present-status register going out of sync, leading to malicious guest using DMA mode and overflowing the FIFO buffer: $ cat << EOF | qemu-system-i386 \ -display none -nographic -nodefaults \ -machine accel=qtest -m 512M \ -device sdhci-pci,sd-spec-version=3 \ -device sd-card,drive=mydrive \ -drive if=none,index=0,file=null-co://,format=raw,id=mydrive \ -qtest stdio outl 0xcf8 0x80001013 outl 0xcfc 0x91 outl 0xcf8 0x80001001 outl 0xcfc 0x06000000 write 0x9100002c 0x1 0x05 write 0x91000058 0x1 0x16 write 0x91000005 0x1 0x04 write 0x91000028 0x1 0x08 write 0x16 0x1 0x21 write 0x19 0x1 0x20 write 0x9100000c 0x1 0x01 write 0x9100000e 0x1 0x20 write 0x9100000f 0x1 0x00 write 0x9100000c 0x1 0x00 write 0x91000020 0x1 0x00 EOF Stack trace (part): ================================================================= ==89993==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000029900 at pc 0x55d5f885700d bp 0x7ffc1e1e9470 sp 0x7ffc1e1e9468 WRITE of size 1 at 0x615000029900 thread T0 #0 0x55d5f885700c in sdhci_write_dataport hw/sd/sdhci.c:564:39 #1 0x55d5f8849150 in sdhci_write hw/sd/sdhci.c:1223:13 #2 0x55d5fa01db63 in memory_region_write_accessor system/memory.c:497:5 #3 0x55d5fa01d245 in access_with_adjusted_size system/memory.c:573:18 #4 0x55d5fa01b1a9 in memory_region_dispatch_write system/memory.c:1521:16 #5 0x55d5fa09f5c9 in flatview_write_continue system/physmem.c:2711:23 #6 0x55d5fa08f78b in flatview_write system/physmem.c:2753:12 #7 0x55d5fa08f258 in address_space_write system/physmem.c:2860:18 ... 0x615000029900 is located 0 bytes to the right of 512-byte region [0x615000029700,0x615000029900) allocated by thread T0 here: #0 0x55d5f7237b27 in __interceptor_calloc #1 0x7f9e36dd4c50 in g_malloc0 #2 0x55d5f88672f7 in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 #3 0x55d5f844b582 in pci_qdev_realize hw/pci/pci.c:2092:9 #4 0x55d5fa2ee74b in device_set_realized hw/core/qdev.c:510:13 #5 0x55d5fa325bfb in property_set_bool qom/object.c:2358:5 #6 0x55d5fa31ea45 in object_property_set qom/object.c:1472:5 #7 0x55d5fa332509 in object_property_set_qobject om/qom-qobject.c:28:10 #8 0x55d5fa31f6ed in object_property_set_bool qom/object.c:1541:15 #9 0x55d5fa2e2948 in qdev_realize hw/core/qdev.c:292:12 #10 0x55d5f8eed3f1 in qdev_device_add_from_qdict system/qdev-monitor.c:719:10 #11 0x55d5f8eef7ff in qdev_device_add system/qdev-monitor.c:738:11 #12 0x55d5f8f211f0 in device_init_func system/vl.c:1200:11 #13 0x55d5fad0877d in qemu_opts_foreach util/qemu-option.c:1135:14 #14 0x55d5f8f0df9c in qemu_create_cli_devices system/vl.c:2638:5 #15 0x55d5f8f0db24 in qmp_x_exit_preconfig system/vl.c:2706:5 #16 0x55d5f8f14dc0 in qemu_init system/vl.c:3737:9 ... SUMMARY: AddressSanitizer: heap-buffer-overflow hw/sd/sdhci.c:564:39 in sdhci_write_dataport Add assertions to ensure the fifo_buffer[] is not overflowed by malicious accesses to the Buffer Data Port register. Fixes: CVE-2024-3447 Cc: qemu-stable@nongnu.org Fixes: d7dfca0807 ("hw/sdhci: introduce standard SD host controller") Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58813 Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <CAFEAcA9iLiv1XGTGKeopgMa8Y9+8kvptvsb8z2OBeuy+5=NUfg@mail.gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409145524.27913-1-philmd@linaro.org> (cherry picked from commit 9e4b27ca6bf4974f169bbca7f3dca117b1208b6f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 17:20:51 UTC
f313079 hw/net/lan9118: Replace magic '2048' value by MIL_TXFIFO_SIZE definition The magic 2048 is explained in the LAN9211 datasheet (DS00002414A) in chapter 1.4, "10/100 Ethernet MAC": The MAC Interface Layer (MIL), within the MAC, contains a 2K Byte transmit and a 128 Byte receive FIFO which is separate from the TX and RX FIFOs. [...] Note, the use of the constant in lan9118_receive() reveals that our implementation is using the same buffer for both tx and rx. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-2-philmd@linaro.org> (cherry picked from commit a45223467e4e185fff1c76a6483784fa379ded77) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 17:20:49 UTC
cd7beea hw/net/lan9118: Fix overflow in MIL TX FIFO When the MAC Interface Layer (MIL) transmit FIFO is full, truncate the packet, and raise the Transmitter Error (TXE) flag. Broken since model introduction in commit 2a42499017 ("LAN9118 emulation"). When using the reproducer from https://gitlab.com/qemu-project/qemu/-/issues/2267 we get: hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')     #0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43     #1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9     #2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9     #3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5     #4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18     #5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16     #6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18     #7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19     #8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12     #9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18 ... [*] LAN9118 DS00002266B.pdf, Table 5.3.3 "INTERRUPT STATUS REGISTER" Cc: qemu-stable@nongnu.org Reported-by: Will Lester Reported-by: Chuhong Yuan <hslester96@gmail.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2267 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-3-philmd@linaro.org> (cherry picked from commit ad766d603f39888309cfb1433ba2de1d0e9e4f58) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:38:59 UTC
734314d backends/cryptodev: Do not abort for invalid session ID Instead of aborting when a session ID is invalid, return VIRTIO_CRYPTO_INVSESS ("Invalid session id"). Reproduced using: $ cat << EOF | qemu-system-i386 -display none \ -machine q35,accel=qtest -m 512M -nodefaults \ -object cryptodev-backend-builtin,id=cryptodev0 \ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ -qtest stdio outl 0xcf8 0x80000804 outw 0xcfc 0x06 outl 0xcf8 0x80000820 outl 0xcfc 0xe0008000 write 0x10800e 0x1 0x01 write 0xe0008016 0x1 0x01 write 0xe0008020 0x4 0x00801000 write 0xe0008028 0x4 0x00c01000 write 0xe000801c 0x1 0x01 write 0x110000 0x1 0x05 write 0x110001 0x1 0x04 write 0x108002 0x1 0x11 write 0x108008 0x1 0x48 write 0x10800c 0x1 0x01 write 0x108018 0x1 0x10 write 0x10801c 0x1 0x02 write 0x10c002 0x1 0x01 write 0xe000b005 0x1 0x00 EOF Assertion failed: (session_id < MAX_NUM_SESSIONS && builtin->sessions[session_id]), function cryptodev_builtin_close_session, file cryptodev-builtin.c, line 430. Cc: qemu-stable@nongnu.org Reported-by: Zheyu Ma <zheyuma97@gmail.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2274 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20240409094757.9127-1-philmd@linaro.org> (cherry picked from commit eaf2bd29538d039df80bb4b1584de33a61312bc6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:38:27 UTC
9b7bc39 hw/misc/applesmc: Fix memory leak in reset() handler AppleSMCData is allocated with g_new0() in applesmc_add_key(): release it with g_free(). Leaked since commit 1ddda5cd36 ("AppleSMC device emulation"). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2272 Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240408095217.57239-3-philmd@linaro.org> (cherry picked from commit fc09ff2979defdcf8d00c2db94022d5d610e36ba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:38:01 UTC
8394be7 hw/block/nand: Fix out-of-bound access in NAND block buffer nand_command() and nand_getio() don't check @offset points into the block, nor the available data length (s->iolen) is not negative. In order to fix: - check the offset is in range in nand_blk_load_NAND_PAGE_SIZE(), - do not set @iolen if blk_load() failed. Reproducer: $ cat << EOF | qemu-system-arm -machine tosa \ -monitor none -serial none \ -display none -qtest stdio write 0x10000111 0x1 0xca write 0x10000104 0x1 0x47 write 0x1000ca04 0x1 0xd7 write 0x1000ca01 0x1 0xe0 write 0x1000ca04 0x1 0x71 write 0x1000ca00 0x1 0x50 write 0x1000ca04 0x1 0xd7 read 0x1000ca02 0x1 write 0x1000ca01 0x1 0x10 EOF ================================================================= ==15750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000000de0 at pc 0x560e61557210 bp 0x7ffcfc4a59f0 sp 0x7ffcfc4a59e8 READ of size 1 at 0x61f000000de0 thread T0 #0 0x560e6155720f in mem_and hw/block/nand.c:101:20 #1 0x560e6155ac9c in nand_blk_write_512 hw/block/nand.c:663:9 #2 0x560e61544200 in nand_command hw/block/nand.c:293:13 #3 0x560e6153cc83 in nand_setio hw/block/nand.c:520:13 #4 0x560e61a0a69e in tc6393xb_nand_writeb hw/display/tc6393xb.c:380:13 #5 0x560e619f9bf7 in tc6393xb_writeb hw/display/tc6393xb.c:524:9 #6 0x560e647c7d03 in memory_region_write_accessor softmmu/memory.c:492:5 #7 0x560e647c7641 in access_with_adjusted_size softmmu/memory.c:554:18 #8 0x560e647c5f66 in memory_region_dispatch_write softmmu/memory.c:1514:16 #9 0x560e6485409e in flatview_write_continue softmmu/physmem.c:2825:23 #10 0x560e648421eb in flatview_write softmmu/physmem.c:2867:12 #11 0x560e64841ca8 in address_space_write softmmu/physmem.c:2963:18 #12 0x560e61170162 in qemu_writeb tests/qtest/videzzo/videzzo_qemu.c:1080:5 #13 0x560e6116eef7 in dispatch_mmio_write tests/qtest/videzzo/videzzo_qemu.c:1227:28 0x61f000000de0 is located 0 bytes to the right of 3424-byte region [0x61f000000080,0x61f000000de0) allocated by thread T0 here: #0 0x560e611276cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 #1 0x7f7959a87e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) #2 0x560e64b98871 in object_new qom/object.c:749:12 #3 0x560e64b5d1a1 in qdev_new hw/core/qdev.c:153:19 #4 0x560e61547ea5 in nand_init hw/block/nand.c:639:11 #5 0x560e619f8772 in tc6393xb_init hw/display/tc6393xb.c:558:16 #6 0x560e6390bad2 in tosa_init hw/arm/tosa.c:250:12 SUMMARY: AddressSanitizer: heap-buffer-overflow hw/block/nand.c:101:20 in mem_and ==15750==ABORTING Broken since introduction in commit 3e3d5815cb ("NAND Flash memory emulation and ECC calculation helpers for use by NAND controllers"). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1445 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1446 Reported-by: Qiang Liu <cyruscyliu@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-4-philmd@linaro.org> (cherry picked from commit d39fdfff348fdf00173b7a58e935328a64db7d28) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:36:00 UTC
9ca7801 hw/block/nand: Have blk_load() take unsigned offset and return boolean Negative offset is meaningless, use unsigned type. Return a boolean value indicating success. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-3-philmd@linaro.org> (cherry picked from commit 2e3e09b368001f7eaeeca7a9b49cb1f0c9092d85) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:36:00 UTC
caeb448 hw/block/nand: Factor nand_load_iolen() method out Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-2-philmd@linaro.org> (cherry picked from commit 7a86544f286d8af4fa5251101c1026ddae92cc3d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:36:00 UTC
d5c41e4 qemu-options: Fix CXL Fixed Memory Window interleave-granularity typo Fix the unit typo of interleave-granularity of CXL Fixed Memory Window in qemu-option.hx. Fixes: 03b39fcf64 ("hw/cxl: Make the CFMW a machine parameter.") Signed-off-by: Yuquan Wang wangyuquan1236@phytium.com.cn Message-ID: <20240407083539.1488172-2-wangyuquan1236@phytium.com.cn> [PMD: Reworded] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit aa88f99c87c0e5d195d6d96190374650553ea61f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:27:46 UTC
7aaf5f7 hw/virtio/virtio-crypto: Protect from DMA re-entrancy bugs Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed. Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Suggested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-5-philmd@linaro.org> (cherry picked from commit f4729ec39ad97a42ceaa7b5697f84f440ea6e5dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:27:04 UTC
e7c2df3 hw/char/virtio-serial-bus: Protect from DMA re-entrancy bugs Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed. Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Suggested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-4-philmd@linaro.org> (cherry picked from commit b4295bff25f7b50de1d9cc94a9c6effd40056bca) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 16:27:04 UTC
6d37a30 hw/display/virtio-gpu: Protect from DMA re-entrancy bugs Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed: $ cat << EOF | qemu-system-i386 -display none -nodefaults \ -machine q35,accel=qtest \ -m 512M \ -device virtio-gpu \ -qtest stdio outl 0xcf8 0x80000820 outl 0xcfc 0xe0004000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0004030 0x4 0x024000e0 write 0xe0004028 0x1 0xff write 0xe0004020 0x4 0x00009300 write 0xe000401c 0x1 0x01 write 0x101 0x1 0x04 write 0x103 0x1 0x1c write 0x9301c8 0x1 0x18 write 0x105 0x1 0x1c write 0x107 0x1 0x1c write 0x109 0x1 0x1c write 0x10b 0x1 0x00 write 0x10d 0x1 0x00 write 0x10f 0x1 0x00 write 0x111 0x1 0x00 write 0x113 0x1 0x00 write 0x115 0x1 0x00 write 0x117 0x1 0x00 write 0x119 0x1 0x00 write 0x11b 0x1 0x00 write 0x11d 0x1 0x00 write 0x11f 0x1 0x00 write 0x121 0x1 0x00 write 0x123 0x1 0x00 write 0x125 0x1 0x00 write 0x127 0x1 0x00 write 0x129 0x1 0x00 write 0x12b 0x1 0x00 write 0x12d 0x1 0x00 write 0x12f 0x1 0x00 write 0x131 0x1 0x00 write 0x133 0x1 0x00 write 0x135 0x1 0x00 write 0x137 0x1 0x00 write 0x139 0x1 0x00 write 0xe0007003 0x1 0x00 EOF ... ================================================================= ==276099==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000011178 at pc 0x562cc3b736c7 bp 0x7ffed49dee60 sp 0x7ffed49dee58 READ of size 8 at 0x60d000011178 thread T0 #0 0x562cc3b736c6 in virtio_gpu_ctrl_response hw/display/virtio-gpu.c:180:42 #1 0x562cc3b7c40b in virtio_gpu_ctrl_response_nodata hw/display/virtio-gpu.c:192:5 #2 0x562cc3b7c40b in virtio_gpu_simple_process_cmd hw/display/virtio-gpu.c:1015:13 #3 0x562cc3b82873 in virtio_gpu_process_cmdq hw/display/virtio-gpu.c:1050:9 #4 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #5 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #6 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5 #7 0x562cc4a8a2da in aio_ctx_dispatch util/async.c:358:5 #8 0x7f36840547a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) #9 0x562cc4a8b753 in glib_pollfds_poll util/main-loop.c:290:9 #10 0x562cc4a8b753 in os_host_main_loop_wait util/main-loop.c:313:5 #11 0x562cc4a8b753 in main_loop_wait util/main-loop.c:592:11 #12 0x562cc3938186 in qemu_main_loop system/runstate.c:782:9 #13 0x562cc43b7af5 in qemu_default_main system/main.c:37:14 #14 0x7f3683a6c189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #15 0x7f3683a6c244 in __libc_start_main csu/../csu/libc-start.c:381:3 #16 0x562cc2a58ac0 in _start (qemu-system-i386+0x231bac0) 0x60d000011178 is located 56 bytes inside of 136-byte region [0x60d000011140,0x60d0000111c8) freed by thread T0 here: #0 0x562cc2adb662 in __interceptor_free (qemu-system-i386+0x239e662) #1 0x562cc3b86b21 in virtio_gpu_reset hw/display/virtio-gpu.c:1524:9 #2 0x562cc416e20e in virtio_reset hw/virtio/virtio.c:2145:9 #3 0x562cc37c5644 in virtio_pci_reset hw/virtio/virtio-pci.c:2249:5 #4 0x562cc4233758 in memory_region_write_accessor system/memory.c:497:5 #5 0x562cc4232eea in access_with_adjusted_size system/memory.c:573:18 previously allocated by thread T0 here: #0 0x562cc2adb90e in malloc (qemu-system-i386+0x239e90e) #1 0x7f368405a678 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5a678) #2 0x562cc4163ffc in virtqueue_split_pop hw/virtio/virtio.c:1612:12 #3 0x562cc4163ffc in virtqueue_pop hw/virtio/virtio.c:1783:16 #4 0x562cc3b91a95 in virtio_gpu_handle_ctrl hw/display/virtio-gpu.c:1112:15 #5 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #6 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #7 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5 SUMMARY: AddressSanitizer: heap-use-after-free hw/display/virtio-gpu.c:180:42 in virtio_gpu_ctrl_response With this change, the same reproducer triggers: qemu-system-i386: warning: Blocked re-entrant IO on MemoryRegion: virtio-pci-common-virtio-gpu at addr: 0x6 Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Yongkang Jia <kangel@zju.edu.cn> Reported-by: Xiao Lei <nop.leixiao@gmail.com> Reported-by: Yiming Tao <taoym@zju.edu.cn> Buglink: https://bugs.launchpad.net/qemu/+bug/1888606 Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-3-philmd@linaro.org> (cherry picked from commit ba28e0ff4d95b56dc334aac2730ab3651ffc3132) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in hw/display/virtio-gpu.c:virtio_gpu_device_realize() due to missing v8.1.0-rc2-69-ga41e2d97f92b "virtio-gpu: reset gfx resources in main thread". Maybe it's worth to pick this too) 10 April 2024, 16:25:48 UTC
e070e5e hw/virtio: Introduce virtio_bh_new_guarded() helper Introduce virtio_bh_new_guarded(), similar to qemu_bh_new_guarded() but using the transport memory guard, instead of the device one (there can only be one virtio device per virtio bus). Inspired-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-2-philmd@linaro.org> (cherry picked from commit ec0504b989ca61e03636384d3602b7bf07ffe4da) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial #include context fixup in include/hw/virtio/virtio.h) 10 April 2024, 16:17:04 UTC
d6e7ec1 linux-user: Fix waitid return of siginfo_t and rusage The copy back to siginfo_t should be conditional only on arg3, not the specific values that might have been written. The copy back to rusage was missing entirely. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2262 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Fan <alex.fan.q@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit f0907ff4cae743f1a4ef3d0a55a047029eed06ff) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 15:54:42 UTC
b198998 tcg/optimize: Do not attempt to constant fold neg_vec Split out the tail of fold_neg to fold_neg_no_const so that we can avoid attempting to constant fold vector negate. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2150 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e25fe886b89a396bae5847520b70c148587d490a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in tests/tcg/aarch64/Makefile.target) 10 April 2024, 15:52:48 UTC
fd01f5a hw/virtio: Fix packed virtqueue flush used_idx In the event of writing many chains of descriptors, the device must write just the id of the last buffer in the descriptor chain, skip forward the number of descriptors in the chain, and then repeat the operations for the rest of chains. Current QEMU code writes all the buffer ids consecutively, and then skips all the buffers altogether. This is a bug, and can be reproduced with a VirtIONet device with _F_MRG_RXBUB and without _F_INDIRECT_DESC: If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature but not the VIRTIO_RING_F_INDIRECT_DESC feature, 'VirtIONetQueue->rx_vq' will use the merge feature to store data in multiple 'elems'. The 'num_buffers' in the virtio header indicates how many elements are merged. If the value of 'num_buffers' is greater than 1, all the merged elements will be filled into the descriptor ring. The 'idx' of the elements should be the value of 'vq->used_idx' plus 'ndescs'. Fixes: 86044b24e8 ("virtio: basic packed virtqueue support") Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Wafer <wafer@jaguarmicro.com> Message-Id: <20240407015451.5228-2-wafer@jaguarmicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2d9a31b3c27311eca1682cb2c076d7a300441960) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:39:50 UTC
227d945 hw/net/virtio-net: fix qemu set used ring flag even vhost started When vhost-user or vhost-kernel is handling virtio net datapath, QEMU should not touch used ring. But with vhost-user socket reconnect scenario, in a very rare case (has pending kick event). VRING_USED_F_NO_NOTIFY is set by QEMU in following code path: #0 virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:511 #1 0x0000559d6dbf033b in virtio_queue_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576 #2 0x0000559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0, vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801 #3 0x0000559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at ../hw/virtio/virtio.c:2248 #4 0x0000559d6dbf79da in virtio_queue_host_notifier_read (n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525 #5 0x0000559d6d9a5814 in virtio_bus_cleanup_host_notifier (bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321 #6 0x0000559d6dbf83c9 in virtio_device_stop_ioeventfd_impl (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774 #7 0x0000559d6d9a55c8 in virtio_bus_stop_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259 #8 0x0000559d6d9a53e8 in virtio_bus_grab_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199 #9 0x0000559d6dbf841c in virtio_device_grab_ioeventfd (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783 #10 0x0000559d6d9bde18 in vhost_dev_enable_notifiers (hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592 #11 0x0000559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70, dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266 #12 0x0000559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0, ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412 #13 0x0000559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:311 #14 0x0000559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:392 #15 0x0000559d6dbb60d8 in virtio_net_set_link_status (nc=0x559d7048d890) at ../hw/net/virtio-net.c:455 #16 0x0000559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1", up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459 #17 0x0000559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0, event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301 #18 0x0000559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:62 #19 0x0000559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:82 This issue causes guest kernel stop kicking device and traffic stop. Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong VRING_USED_F_NO_NOTIFY set. Signed-off-by: Yajun Wu <yajunw@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20240402045109.97729-1-yajunw@nvidia.com> [PMD: Use unlikely()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 4c54f5bc8e1d38f15cc35b6a6932d8fbe219c692) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
393b7ab hw/intc/arm_gicv3: ICC_HPPIR* return SPURIOUS if int group is disabled If the group of the highest priority pending interrupt is disabled via ICC_IGRPEN*, the ICC_HPPIR* registers should return INTID_SPURIOUS, not the interrupt ID. (See the GIC architecture specification pseudocode functions ICC_HPPIR1_EL1[] and HighestPriorityPendingInterrupt().) Make HPPIR reads honour the group disable, the way we already do when determining whether to preempt in icc_hppi_can_preempt(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240328153333.2522667-1-peter.maydell@linaro.org (cherry picked from commit 44e25fbc1900c99c91a44e532c5bd680bc403459) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
eebb7fb gitlab-ci/cirrus: switch from 'master' to 'latest' Commit ab72522797 "gitlab: switch from 'stable' to 'latest' docker container tags" switched most tags to 'latest' but missed cirrus image. Fix this now. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2256 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Message-id: 20240401051633.2780456-1-mjt@tls.msk.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1d2f2b35bc86b7a13dc3009a3c5031220aa0b7de) 09 April 2024, 17:09:20 UTC
6fca92c target/hppa: Clear psw_n for BE on use_nullify_skip path Along this path we have already skipped the insn to be nullified, so the subsequent insn should be executed. Cc: qemu-stable@nongnu.org Reported-by: Sven Schnelle <svens@stackframe.org> Tested-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4a3aa11e1fb25c28c24a43fd2835c429b00a463d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
162c54b tcg/optimize: Fix sign_mask for logical right-shift The 'sign' computation is attempting to locate the sign bit that has been repeated, so that we can test if that bit is known zero. That computation can be zero if there are no known sign repetitions. Cc: qemu-stable@nongnu.org Fixes: 93a967fbb57 ("tcg/optimize: Propagate sign info for shifting") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2248 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 2911e9b95f3bb03783ae5ca3e2494dc3b44a9161) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial context fixup in tests/tcg/aarch64/Makefile.target) 09 April 2024, 17:09:20 UTC
493b1cc virtio-net: Fix vhost virtqueue notifiers for RSS virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask() checked VIRTIO_NET_F_MQ to know there are multiple queues, but VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue, which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is enabled. Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for vhost_vdpa") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 1c188fc8cbffc5f05cc616cab4e1372fb6e6f11f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
70b0e14 monitor/hmp-cmds-target: Append a space in error message in gpa2hva() In qemu monitor mode, when we use gpa2hva command to print the host virtual address corresponding to a guest physical address, if the gpa is not in RAM, the error message is below: (qemu) gpa2hva 0x750000000 Memory at address 0x750000000is not RAM A space is missed between '0x750000000' and 'is'. Signed-off-by: Yao Xingtao <yaoxt.fnst@fujitsu.com> Fixes: e9628441df ("hmp: gpa2hva and gpa2hpa hostaddr command") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Message-ID: <20240319021610.2423844-1-ruansy.fnst@fujitsu.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit a158c63b3ba120f1656e4dd815d186c623fb5ef6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: in 7.2. it is in monitor/misc.c, not in monitor/hmp-cmds-target.c) 09 April 2024, 17:09:20 UTC
2e1645a hw/scsi/scsi-generic: Fix io_timeout property not applying The io_timeout property, introduced in c9b6609 (part of 6.0) is silently overwritten by the hardcoded default value of 30 seconds (DEFAULT_IO_TIMEOUT) in scsi_generic_realize because that function is being called after the properties have already been applied. The property definition already has a default value which is applied correctly when no value is explicitly set, so we can just remove the code which overrides the io_timeout completely. This has been tested by stracing SG_IO operations with the io_timeout property set and unset and now sets the timeout field in the ioctl request to the proper value. Fixes: c9b6609b69facad ("scsi: make io_timeout configurable") Signed-off-by: Lorenz Brun <lorenz@brun.one> Message-ID: <20240315145831.2531695-1-lorenz@brun.one> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 7c7a9f578e4fb1adff7ac8d9acaaaedb87474e76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
610db16 target/loongarch: Fix qemu-system-loongarch64 assert failed with the option '-d int' qemu-system-loongarch64 assert failed with the option '-d int', the helper_idle() raise an exception EXCP_HLT, but the exception name is undefined. Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240321123606.1704900-1-gaosong@loongson.cn> (cherry picked from commit 1590154ee4376819a8c6ee61e849ebf4a4e7cd02) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup for lack of 2 commits adding new entries into excp_names[]: v8.0.0-514-ga3f3db5cda "target/loongarch: Add CHECK_SXE maccro for check LSX enable" and v8.1.0-801-gb8f1bdf3d1 "target/loongarch: check_vec support check LASX instructions") 09 April 2024, 17:09:20 UTC
e9e4144 target/i386: Revert monitor_puts() in do_inject_x86_mce() monitor_puts() doesn't check the monitor pointer, but do_inject_x86_mce() may have a parameter with NULL monitor pointer. Revert monitor_puts() in do_inject_x86_mce() to fix, then the fact that we send the same message to monitor and log is again more obvious. Fixes: bf0c50d4aa85 (monitor: expose monitor_puts to rest of code) Reviwed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Message-ID: <20240320083640.523287-1-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 7fd226b04746f0be0b636de5097f1b42338951a0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:09:20 UTC
a6fc9a2 target/i386: fix direction of "32-bit MMU" test The low bit of MMU indices for x86 TCG indicates whether the processor is in 32-bit mode and therefore linear addresses have to be masked to 32 bits. However, the index was computed incorrectly, leading to possible conflicts in the TLB for any address above 4G. Analyzed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: b1661801c18 ("target/i386: Fix physical address truncation", 2024-02-28) Fixes: 1c15f97b4f1 ("target/i386: Fix physical address truncation" in stable-7.2) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2206 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2cc68629a6fc198f4a972698bdd6477f883aedfb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: move changes for x86_cpu_mmu_index() to cpu_mmu_index() due to missing v8.2.0-1030-gace0c5fe59 "target/i386: Populate CPUClass.mmu_index") 09 April 2024, 17:09:20 UTC
ad00365 target/i386: use separate MMU indexes for 32-bit accesses Accesses from a 32-bit environment (32-bit code segment for instruction accesses, EFER.LMA==0 for processor accesses) have to mask away the upper 32 bits of the address. While a bit wasteful, the easiest way to do so is to use separate MMU indexes. These days, QEMU anyway is compiled with a fixed value for NB_MMU_MODES. Split MMU_USER_IDX, MMU_KSMAP_IDX and MMU_KNOSMAP_IDX in two. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 90f641531c782c873a05895f411c05fbbbef3c49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: move changes for x86_cpu_mmu_index() to cpu_mmu_index() due to missing v8.2.0-1030-gace0c5fe5950 "target/i386: Populate CPUClass.mmu_index" Increase NB_MMU_MODES from 5 to 8 in target/i386/cpu-param.h due to missing v7.2.0-2640-gffd824f3f32d "include/exec: Set default NB_MMU_MODES to 16" v7.2.0-2647-g6787318a5d86 "target/i386: Remove NB_MMU_MODES define" which relaxed upper limit of MMU index for i386, since this commit starts using MMU_NESTED_IDX=7. Thanks Zhao Liu and Paolo Bonzini for the analisys and suggestions. ) 09 April 2024, 17:06:31 UTC
6332f3c target/i386: introduce function to query MMU indices Remove knowledge of specific MMU indexes (other than MMU_NESTED_IDX and MMU_PHYS_IDX) from mmu_translate(). This will make it possible to split 32-bit and 64-bit MMU indexes. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5f97afe2543f09160a8d123ab6e2e8c6d98fa9ce) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in target/i386/cpu.h due to other changes in that area) 21 March 2024, 16:55:44 UTC
e4b2389 tests: Raise timeouts for bufferiszero and crypto-tlscredsx509 On our gcov CI job, the bufferiszero and crypto-tlscredsx509 tests time out occasionally, making the job flaky. Double the timeout on these two tests. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2221 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240312110815.116992-1-peter.maydell@linaro.org (cherry picked from commit 55f7c6a5f2bd82e1d2d0eac6eee0185ce0451815) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 March 2024, 14:34:47 UTC
9405029 tests/unit: Bump test-replication timeout to 60 seconds We're seeing timeouts for this test on CI runs (specifically for ubuntu-20.04-s390x-all). It doesn't fail consistently, but even the successful runs take about 27 or 28 seconds, which is not very far from the 30 seconds timeout. Bump the timeout a bit to make failure less likely even on this CI host. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240125165803.48373-1-kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 63b18312d14ac984acaf13c7c55d9baa2d61496e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 March 2024, 14:34:47 UTC
4f048b7 tests/unit: Bump test-crypto-block test timeout to 5 minutes When running the tests in slow mode on a very loaded system and with --enable-debug, the test-crypto-block can take longer than 4 minutes. Bump the timeout to 5 minutes to make sure that it also passes in such situations. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-15-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit e1b363e328d559cd5f86d3d1d7b84d0154e153d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 March 2024, 14:34:26 UTC
dcb9a64 tests/unit: Bump test-aio-multithread test timeout to 2 minutes When running the tests in slow mode on a very loaded system and with --enable-debug, the test-aio-multithread can take longer than 1 minute. Bump the timeout to two minutes to make sure that it also passes in such situations. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-14-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit c45f8f1aef35730a2dcf3cabe296ac12965db43d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 March 2024, 14:34:20 UTC
e1e9d74 migration: Skip only empty block devices The block .save_setup() handler calls a helper routine init_blk_migration() which builds a list of block devices to take into account for migration. When one device is found to be empty (sectors == 0), the loop exits and all the remaining devices are ignored. This is a regression introduced when bdrv_iterate() was removed. Change that by skipping only empty devices. Cc: Markus Armbruster <armbru@redhat.com> Cc: qemu-stable <qemu-stable@nongnu.org> Suggested-by: Kevin Wolf <kwolf@redhat.com> Fixes: fea68bb6e9fa ("block: Eliminate bdrv_iterate(), use bdrv_next()") Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Link: https://lore.kernel.org/r/20240312120431.550054-1-clg@redhat.com [peterx: fix "Suggested-by:"] Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 2e128776dc56f502c2ee41750afe83938f389528) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 March 2024, 16:23:00 UTC
04b3d34 hmat acpi: Fix out of bounds access due to missing use of indirection With a numa set up such as -numa nodeid=0,cpus=0 \ -numa nodeid=1,memdev=mem \ -numa nodeid=2,cpus=1 and appropriate hmat_lb entries the initiator list is correctly computed and writen to HMAT as 0,2 but then the LB data is accessed using the node id (here 2), landing outside the entry_list array. Stash the reverse lookup when writing the initiator list and use it to get the correct array index index. Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240307160326.31570-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 74e2845c5f95b0c139c79233ddb65bb17f2dd679) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
309051a pcie_sriov: Validate NumVFs The guest may write NumVFs greater than TotalVFs and that can lead to buffer overflow in VF implementations. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26327 Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-2-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> (cherry picked from commit 6081b4243cd64dff1b2cf5b0c215c71e9d7e753b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
3f7892b hw/nvme: Use pcie_sriov_num_vfs() nvme_sriov_pre_write_ctrl() used to directly inspect SR-IOV configurations to know the number of VFs being disabled due to SR-IOV configuration writes, but the logic was flawed and resulted in out-of-bound memory access. It assumed PCI_SRIOV_NUM_VF always has the number of currently enabled VFs, but it actually doesn't in the following cases: - PCI_SRIOV_NUM_VF has been set but PCI_SRIOV_CTRL_VFE has never been. - PCI_SRIOV_NUM_VF was written after PCI_SRIOV_CTRL_VFE was set. - VFs were only partially enabled because of realization failure. It is a responsibility of pcie_sriov to interpret SR-IOV configurations and pcie_sriov does it correctly, so use pcie_sriov_num_vfs(), which it provides, to get the number of enabled VFs before and after SR-IOV configuration writes. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26328 Fixes: 11871f53ef8e ("hw/nvme: Add support for the Virtualization Management command") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-1-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 91bb64a8d2014fda33a81fcf0fce37340f0d3b0c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
e00b062 pcie: Introduce pcie_sriov_num_vfs igb can use this function to change its behavior depending on the number of virtual functions currently enabled. Signed-off-by: Gal Hammer <gal.hammer@sap.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 31180dbdca2859ae9841939f85158908453ea01d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: needed for v8.2.0-2290-g91bb64a8d2 "hw/nvme: Use pcie_sriov_num_vfs()" (CVE-2024-26328)) 14 March 2024, 18:24:34 UTC
0b7ccfd hw/nvme: add machine compatibility parameter to enable msix exclusive bar Commit 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") moved the MSI-X table and PBA to BAR 0 to make room for enabling CMR and PMR at the same time. As reported by Julien Grall in #2184, this breaks migration through system hibernation. Add a machine compatibility parameter and set it on machines pre 6.0 to enable the old behavior automatically, restoring the hibernation migration support. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2184 Fixes: 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") Reported-by: Julien Grall julien@xen.org Tested-by: Julien Grall julien@xen.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit fa905f65c5549703279f68c253914799b10ada47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
6a5d684 hw/nvme: generalize the mbar size helper Generalize the mbar size helper such that it can handle cases where the MSI-X table and PBA are expected to be in an exclusive bar. Cc: qemu-stable@nongnu.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit ee7bda4d38cda3eaf114c850a723dd12e23d3abc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
424e620 hw/nvme: separate 'serial' property for VFs Currently, when a VF is created, it uses the 'params' object of the PF as it is. In other words, the 'params.serial' string memory area is also shared. In this situation, if the VF is removed from the system, the PF's 'params.serial' object is released with object_finalize() followed by object_property_del_all() which release the memory for 'serial' property. If that happens, the next VF created will inherit a serial from a corrupted memory area. If this happens, an error will occur when comparing subsys->serial and n->params.serial in the nvme_subsys_register_ctrl() function. Cc: qemu-stable@nongnu.org Fixes: 44c2c09488db ("hw/nvme: Add support for SR-IOV") Signed-off-by: Minwoo Im <minwoo.im@samsung.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 4f0a4a3d5854824e5c5eccf353d4a1f4f749a29d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 March 2024, 18:24:34 UTC
5c3889b hw/nvme: cleanup error reporting in nvme_init_pci() Replace the local Error variable with errp and ERRP_GUARD() and change the return value to bool. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 973f76cf7743545a5d8a0a8bfdfe2cd02aa3e238) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: needed for v8.2.0-2319-gfa905f65c5 "hw/nvme: add machine compatibility parameter to enable msix exclusive bar") 14 March 2024, 18:24:34 UTC
201c970 hw/nvme: clean up confusing use of errp/local_err Remove an unnecessary local Error value in nvme_realize(). In the process, change nvme_check_constraints() to return a bool. Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 784fd35387e9e6b42e3f365ddf44263eb25de8f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: needed for v8.2.0-2319-gfa905f65c5 "hw/nvme: add machine compatibility parameter to enable msix exclusive bar") 14 March 2024, 18:24:34 UTC
edb4755 Avoid unaligned fetch in ladr_match() There is no guarantee that the PCNetState is allocated such that csr[8] is allocated on an 8-byte boundary. Since not all hosts are capable of unaligned fetches the 16-bit elements need to be fetched individually to avoid a potential fault. Closes issue #2143 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2143 Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 6a5287ce80470bb8df95901d73ee779a64e70c3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
df052d6 e1000e: fix link state on resume On resume e1000e_vm_state_change() always calls e1000e_autoneg_resume() that sets link_down to false, and thus activates the link even if we have disabled it. The problem can be reproduced starting qemu in paused state (-S) and then set the link to down. When we resume the machine the link appears to be up. Reproducer: # qemu-system-x86_64 ... -device e1000e,netdev=netdev0,id=net0 -S {"execute": "qmp_capabilities" } {"execute": "set_link", "arguments": {"name": "net0", "up": false}} {"execute": "cont" } To fix the problem, merge the content of e1000e_vm_state_change() into e1000e_core_post_load() as e1000 does. Buglink: https://issues.redhat.com/browse/RHEL-21867 Fixes: 6f3fbe4ed06a ("net: Introduce e1000e device emulation") Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 4cadf10234989861398e19f3bb441d3861f3bb7c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
f1efd85 make-release: switch to .xz format by default For a long time, we provide two compression formats in the download area, .bz2 and .xz. There's absolutely no reason to provide two in parallel, .xz compresses better, and all the links we use points to .xz. Downstream distributions mostly use .xz too. For the release maintenance providing two formats is definitely extra burden too. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 9bc9e95119445d7a430b0fc8b7daf22a3612bbd3) 13 March 2024, 20:09:00 UTC
eeb5699 hw/scsi/lsi53c895a: add timer to scripts processing HP-UX 10.20 seems to make the lsi53c895a spinning on a memory location under certain circumstances. As the SCSI controller and CPU are not running at the same time this loop will never finish. After some time, the check loop interrupts with a unexpected device disconnect. This works, but is slow because the kernel resets the scsi controller. Instead of signaling UDC, start a timer and exit the loop. Until the timer fires, the CPU can process instructions which might changes the memory location. The limit of instructions is also reduced because scripts running on the SCSI processor are usually very short. This keeps the time until the loop is exit short. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-ID: <20240229204407.1699260-1-svens@stackframe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9876359990dd4c8a48de65cf5e1c3d13e96a7f4e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
275436d hw/scsi/lsi53c895a: add missing decrement of reentrancy counter When the maximum count of SCRIPTS instructions is reached, the code stops execution and returns, but fails to decrement the reentrancy counter. This effectively renders the SCSI controller unusable because on next entry the reentrancy counter is still above the limit. This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS loops. Fixes: b987718bbb ("hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330)") Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-ID: <20240128202214.2644768-1-svens@stackframe.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8b09b7fe47082c69295a0fc0cc01b041b6385025) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
c57a6fc hw/scsi/lsi53c895a: stop script on phase mismatch Netbsd isn't happy with qemu lsi53c895a emulation: cd0(esiop0:0:2:0): command with tag id 0 reset esiop0: autoconfiguration error: phase mismatch without command esiop0: autoconfiguration error: unhandled scsi interrupt, sist=0x80 sstat1=0x0 DSA=0x23a64b1 DSP=0x50 This is because lsi_bad_phase() triggers a phase mismatch, which stops SCRIPT processing. However, after returning to lsi_command_complete(), SCRIPT is restarted with lsi_resume_script(). Fix this by adding a return value to lsi_bad_phase(), and only resume script processing when lsi_bad_phase() didn't trigger a host interrupt. Signed-off-by: Sven Schnelle <svens@stackframe.org> Tested-by: Helge Deller <deller@gmx.de> Message-ID: <20240302214453.2071388-1-svens@stackframe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a9198b3132d81a6bfc9fdbf6f3d3a514c2864674) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
e55ec34 system/qdev-monitor: move drain_call_rcu call under if (!dev) in qmp_device_add() Original goal of addition of drain_call_rcu to qmp_device_add was to cover the failure case of qdev_device_add. It seems call of drain_call_rcu was misplaced in 7bed89958bfbf40df what led to waiting for pending RCU callbacks under happy path too. What led to overall performance degradation of qmp_device_add. In this patch call of drain_call_rcu moved under handling of failure of qdev_device_add. Signed-off-by: Dmitrii Gavrilov <ds-gavr@yandex-team.ru> Message-ID: <20231103105602.90475-1-ds-gavr@yandex-team.ru> Fixes: 7bed89958bf ("device_core: use drain_call_rcu in in qmp_device_add", 2020-10-12) Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 012b170173bcaa14b9bc26209e0813311ac78489) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
ce25256 hw/rtc/sun4v-rtc: Relicense to GPLv2-or-later The sun4v RTC device model added under commit a0e893039cf2ce0 in 2016 was unfortunately added with a license of GPL-v3-or-later, which is not compatible with other QEMU code which has a GPL-v2-only license. Relicense the code in the .c and the .h file to GPL-v2-or-later, to make it compatible with the rest of QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini (for Red Hat) <pbonzini@redhat.com> Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240223161300.938542-1-peter.maydell@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit fd7f95f23d6fe485332c1d4b489eb719fcb7c225) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
518c3df target/arm: Fix SME full tile indexing For the outer product set of insns, which take an entire matrix tile as output, the argument is not a combined tile+column. Therefore using get_tile_rowcol was incorrect, as we extracted the tile number from itself. The test case relies only on assembler support for SME, since no release of GCC recognizes -march=armv9-a+sme yet. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1620 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230622151201.1578522-5-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: dropped now-unneeded changes to sysregs CFLAGS] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1f51573f7925b80e79a29f87c7d9d6ead60960c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 March 2024, 20:09:00 UTC
13cf40e tests/tcg/aarch64/sysregs.c: Use S syntax for id_aa64zfr0_el1 and id_aa64smfr0_el1 Some assemblers will complain about attempts to access id_aa64zfr0_el1 and id_aa64smfr0_el1 by name if the test binary isn't built for the right processor type: /tmp/ccASXpLo.s:782: Error: selected processor does not support system register name 'id_aa64zfr0_el1' /tmp/ccASXpLo.s:829: Error: selected processor does not support system register name 'id_aa64smfr0_el1' However, these registers are in the ID space and are guaranteed to read-as-zero on older CPUs, so the access is both safe and sensible. Switch to using the S syntax, as we already do for ID_AA64ISAR2_EL1 and ID_AA64MMFR2_EL1. This allows us to drop the HAS_ARMV9_SME check and the makefile machinery to adjust the CFLAGS for this test, so we don't rely on having a sufficiently new compiler to be able to check these registers. This means we're actually testing the SME ID register: no released GCC yet recognizes -march=armv9-a+sme, so that was always skipped. It also avoids a future problem if we try to switch the "do we have SME support in the toolchain" check from "in the compiler" to "in the assembler" (at which point we would otherwise run into the above errors). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3dc2afeab2964b54848715b913b6c605f36be3e1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: pick this for v8.0.0-2361-g1f51573f79 "target/arm: Fix SME full tile indexing") 13 March 2024, 20:08:45 UTC
4002b76 target/arm: align exposed ID registers with Linux In CPUID registers exposed to userspace, some registers were missing and some fields were not exposed. This patch aligns exposed ID registers and their fields with what the upstream kernel currently exposes. Specifically, the following new ID registers/fields are exposed to userspace: ID_AA64PFR1_EL1.BT: bits 3-0 ID_AA64PFR1_EL1.MTE: bits 11-8 ID_AA64PFR1_EL1.SME: bits 27-24 ID_AA64ZFR0_EL1.SVEver: bits 3-0 ID_AA64ZFR0_EL1.AES: bits 7-4 ID_AA64ZFR0_EL1.BitPerm: bits 19-16 ID_AA64ZFR0_EL1.BF16: bits 23-20 ID_AA64ZFR0_EL1.SHA3: bits 35-32 ID_AA64ZFR0_EL1.SM4: bits 43-40 ID_AA64ZFR0_EL1.I8MM: bits 47-44 ID_AA64ZFR0_EL1.F32MM: bits 55-52 ID_AA64ZFR0_EL1.F64MM: bits 59-56 ID_AA64SMFR0_EL1.F32F32: bit 32 ID_AA64SMFR0_EL1.B16F32: bit 34 ID_AA64SMFR0_EL1.F16F32: bit 35 ID_AA64SMFR0_EL1.I8I32: bits 39-36 ID_AA64SMFR0_EL1.F64F64: bit 48 ID_AA64SMFR0_EL1.I16I64: bits 55-52 ID_AA64SMFR0_EL1.FA64: bit 63 ID_AA64MMFR0_EL1.ECV: bits 63-60 ID_AA64MMFR1_EL1.AFP: bits 47-44 ID_AA64MMFR2_EL1.AT: bits 35-32 ID_AA64ISAR0_EL1.RNDR: bits 63-60 ID_AA64ISAR1_EL1.FRINTTS: bits 35-32 ID_AA64ISAR1_EL1.BF16: bits 47-44 ID_AA64ISAR1_EL1.DGH: bits 51-48 ID_AA64ISAR1_EL1.I8MM: bits 55-52 ID_AA64ISAR2_EL1.WFxT: bits 3-0 ID_AA64ISAR2_EL1.RPRES: bits 7-4 ID_AA64ISAR2_EL1.GPA3: bits 11-8 ID_AA64ISAR2_EL1.APA3: bits 15-12 The code is also refactored to use symbolic names for ID register fields for better readability and maintainability. The test case in tests/tcg/aarch64/sysregs.c is also updated to match the intended behavior. Signed-off-by: Zhuojia Shen <chaosdefinition@hotmail.com> Message-id: DS7PR12MB6309FB585E10772928F14271ACE79@DS7PR12MB6309.namprd12.prod.outlook.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: use Sn_n_Cn_Cn_n syntax to work with older assemblers that don't recognize id_aa64isar2_el1 and id_aa64mmfr2_el1] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit bc6bd20ee3538347afb750c4bd06edca4a922897) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: pick this for v8.0.0-2361-g1f51573f79 "target/arm: Fix SME full tile indexing") 13 March 2024, 20:08:08 UTC
331c0fa ui/cocoa: Fix window clipping on macOS 14 macOS Sonoma changes the NSView.clipsToBounds to false by default where it was true in earlier version of macOS. This causes the window contents to be occluded by the frame at the top of the window. This fixes the issue by conditionally compiling the clipping on Sonoma to true. NSView only exposes the clipToBounds in macOS 14 and so has to be fixed via conditional compilation. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1994 Signed-off-by: David Parsons <dave@daveparsons.net> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20240224140620.39200-1-dave@daveparsons.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit f5af80271aad356233b2bea2369b3b2211fa395d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 March 2024, 15:59:36 UTC
aba89ef gitlab: update FreeBSD Cirrus CI image to 13.3 The 13.2 images have been deleted from gcloud Cc: qemu-stable@nongnu.org Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240304144456.3825935-3-berrange@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 9ea920dc28254cd9a363aaef01985dffd8abedd7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: 7.2 used FreeBSD version 13.1, not 13.2) 05 March 2024, 14:47:36 UTC
eee83fa Update version for 7.2.10 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 04 March 2024, 12:14:39 UTC
0ee0f9d target/i386: the sgx_epc_get_section stub is reachable The sgx_epc_get_section stub is reachable from cpu_x86_cpuid. It should not assert, instead it should just return true just like the "real" sgx_epc_get_section does when SGX is disabled. Reported-by: Vladimír Beneš <vbenes@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20220201190941.106001-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 219615740425d9683588207b40a365e6741691a6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 19:06:10 UTC
90b1b8e tests/unit/test-blockjob: Disable complete_in_standby test The blockjob/complete_in_standby test is flaky and fails intermittently in CI: 172/621 qemu:unit / test-blockjob ERROR 0.26s killed by signal 6 SIGABRT 11:03:46 MALLOC_PERTURB_=176 G_TEST_SRCDIR=/Users/pm215/src/qemu-for-merges/tests/unit G_TEST_BUILDDIR=/Users/pm215/src/qemu-for-merges/build/all/tests/unit /Users/pm215/src/qemu-for-merges/build/all/tests/unit/test-blockjob --tap -k ----------------------------------- output ----------------------------------- stdout: # random seed: R02S8c79d6e1c01ce0b25475b2210a253242 1..9 # Start of blockjob tests ok 1 /blockjob/ids stderr: Assertion failed: (job->status == JOB_STATUS_STANDBY), function test_complete_in_standby, file ../../tests/unit/test-blockjob.c, line 499. Seen on macOS/x86_64, FreeBSD 13/x86_64, msys2-64bit, eg: https://gitlab.com/qemu-project/qemu/-/jobs/3872508803 https://gitlab.com/qemu-project/qemu/-/jobs/3950667240 Disable this subtest until somebody has time to investigate. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20230317143534.1481947-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit b6903cbe3a2e3feb7204636209b5607e70fee998) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 19:06:10 UTC
b0ed25e tests/qtest/display-vga-test: Add proper checks if a device is available display-vga-test currently tries to guess the usable VGA devices according to the target architecture that is used for the test. This of course does not work if QEMU has been built with the "--without-default-devices" configure switch. To fix this, use the qtest_has_device() function for the decision instead. This way we can also consolidate most of the test functions into one single function (that takes a parameter with the device name now), except for the multihead test that tries to instantiate two devices and thus is a little bit different. Message-Id: <20230130104446.1286773-4-thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit f2e57851b831922625f9d364d78c11a0258331a6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 19:06:10 UTC
73bf928 test-vmstate: fix bad GTree usage, use-after-free According to g_tree_foreach() documentation: "The tree may not be modified while iterating over it (you can't add/remove items)." compare_trees()/diff_tree() fail to respect this rule. Historically GLib2 used a slice allocator for the GTree APIs which did not immediately release the memory back to the system allocator. As a result QEMU's use-after-free bug was not visible. With GLib > 2.75.3 however, GLib2 has switched to using malloc and now a SIGSEGV can be observed while running test-vmstate. Get rid of the node removal within the tree traversal. Also check the trees have the same number of nodes before the actual diff. Fixes: 9a85e4b8f6 ("migration: Support gtree migration") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1518 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit abe2c4bdb65e8dd9cb2f01c355baa394bf49a8af) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 19:06:10 UTC
72e2a24 tests/unit/test-util-sockets: Remove temporary file after test test-util-sockets leaves the temporary socket files around in the temporary files folder. Let's better remove them at the end of the testing. Fixes: 4d3a329af5 ("tests/util-sockets: add abstract unix socket cases") Message-ID: <20240226082728.249753-1-thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit f0cb6828ae34fb56fbb869bb3147a636d1c984ce) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 16:00:07 UTC
8dd9165 hw/usb/bus.c: PCAP adding 0xA in Windows version Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. This is due to the fact that the PCAP file is opened as TEXT instead of BINARY. To show an example, when using a very common protocol to USB disks, the BBB protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10) command will have a command block length of 10 (0xA). When this 10-byte command (part of the 31-byte CBW) is placed into the PCAP file, the Windows file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a 32-byte CBW. Actual CBW: 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC...........% 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... PCAP CBW 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............ 0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. I believe simply opening the PCAP file as BINARY instead of TEXT will fix this issue. Resolves: https://bugs.launchpad.net/qemu/+bug/2054889 Signed-off-by: Benjamin David Lunt <benlunt@fysnet.net> Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net> [thuth: Break long line to avoid checkpatch.pl error] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 5e02a4fdebc442e34c5bb05e4540f85cc6e802f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 March 2024, 15:59:25 UTC
9b89d02 gitlab: force allow use of pip in Cirrus jobs Python is transitioning to a world where you're not allowed to use 'pip install' outside of a virutal env by default. The rationale is to stop use of pip clashing with distro provided python packages, which creates a major headache on distro upgrades. All our CI environments, however, are 100% disposable so the upgrade headaches don't exist. Thus we can undo the python defaults to allow pip to work. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20240222114038.2348718-1-berrange@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a8bf9de2f4f398315ac5340e4b88c478d5457731) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 28 February 2024, 21:05:02 UTC
4934f92 tests/vm: avoid re-building the VM images all the time The main problem is that "check-venv" is a .PHONY target will always evaluate and trigger a full re-build of the VM images. While its tempting to drop it from the dependencies that does introduce a breakage on freshly configured builds. Fortunately we do have the otherwise redundant --force flag for the script which up until now was always on. If we make the usage of --force conditional on dependencies other than check-venv triggering the update we can avoid the costly rebuild and still run cleanly on a fresh checkout. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2118 Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-4-alex.bennee@linaro.org> (cherry picked from commit 151b7dba391fab64cc008a1fdba6ddcf6f8c39c8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 28 February 2024, 18:21:07 UTC
2bd4d27 tests/vm: update openbsd image to 7.4 The old links are dead so even if we have the ISO cached we can't finish the install. Update to the current stable and tweak the install strings. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2192 Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-5-alex.bennee@linaro.org> (cherry picked from commit 8467ac75b3b7207a49a1c6c7b87f0f7d2d0cea18) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 28 February 2024, 18:20:08 UTC
back to top