When we remove dest from orig's links, we lose the link
that we rely on later to reset links. This can lead to
failure to release from spinlock with self-modifying code.
Cc: qemu-stable@nongnu.org Reported-by: 李威威 <liweiwei@kubuds.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Tested-by: Anton Johansson <anjo@rev.ng>
(cherry picked from commit 03fe6659803f83690b8587d01f8ee56bb4be4b90) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Thu, 18 Sep 2025 12:51:54 +0000 (14:51 +0200)]
tests: Fix "make check-functional" for targets without thorough tests
If QEMU gets configured for a single target that does not have
any thorough functional tests, "make check-functional" currently
fails with the error message "No rule to make target 'check-func'".
This happens because "check-func" only gets defined for thorough
tests (quick ones get added to "check-func-quick" instead).
The same problem can happen with the quick tests for targets that
do not have any functional test at all. To fix it, simply make sure
that the targets are always available in the Makefile.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Closes: https://gitlab.com/qemu-project/qemu/-/issues/3119 Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250918125154.126072-1-thuth@redhat.com>
(cherry picked from commit 4f1ebc7712a7db61155080164f2169320d033559) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Tue, 16 Sep 2025 16:30:30 +0000 (17:30 +0100)]
.gitlab-ci.d/buildtest.yml: Unset CI_COMMIT_DESCRIPTION for htags
In commit 52a21689cd829 we added a workaround for a bug in older
versions of htags where they fail with a weird error message if the
environment is too large. However, we missed one variable which
gitlab CI can set to the body of the commit message:
CI_COMMIT_DESCRIPTION.
Add this to the variables we unset when running htags, so that
the 'pages' job doesn't fail if the most recent commit happens
to have a very large commit message.
Cc: qemu-stable@nongnu.org Fixes: 52a21689cd8 (".gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250916163030.1467893-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit fd34f56fe886250bdd64f9c222c1cb4c07a594ad) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 18 Sep 2025 11:42:59 +0000 (12:42 +0100)]
hw/pci-host/astro: Don't call pci_regsiter_root_bus() in init
In the astro PCI host bridge device, we call pci_register_root_bus()
in the device's instance_init. This is a problem for two reasons
* the PCI bridge is then available to the rest of the simulation
(e.g. via pci_qdev_find_device()), even though it hasn't
yet been realized
* we do not attempt to unregister in an instance_deinit,
which means that if you go through an instance_init -> deinit
lifecycle the freed memory for the host-bridge device is
left on the pci_host_bridges list
ASAN reports the resulting use-after-free:
==1776584==ERROR: AddressSanitizer: heap-use-after-free on address 0x51f00000cb00 at pc 0x5b2d460a89b5 bp 0x7ffef7617f50 sp 0x7ffef7617f48
WRITE of size 8 at 0x51f00000cb00 thread T0
#0 0x5b2d460a89b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5
#1 0x5b2d46093566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5
#2 0x5b2d460935e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5
#3 0x5b2d46093fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11
#4 0x5b2d46fe2335 in elroy_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/astro.c:455:16
0x51f00000cb00 is located 1664 bytes inside of 3456-byte region [0x51f00000c480,0x51f00000d200)
freed by thread T0 here:
#0 0x5b2d4582385a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8)
#1 0x5b2d47160723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9
#2 0x5b2d471589db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9
#3 0x5b2d477d373c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5
previously allocated by thread T0 here:
#0 0x5b2d45823af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8)
#1 0x79728fa08b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5b2d471595fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15
#3 0x5b2d47159409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12
#4 0x5b2d477d29a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11
Cc: qemu-stable@nongnu.org Fixes: e029bb00a79be ("hw/pci-host: Add Astro system bus adapter found on PA-RISC machines")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250918114259.1802337-3-peter.maydell@linaro.org>
(cherry picked from commit 76d2b8d42adb0db2d1ccd08a626f25ddd30208a8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 18 Sep 2025 11:42:58 +0000 (12:42 +0100)]
hw/pci-host/dino: Don't call pci_register_root_bus() in init
In the dino PCI host bridge device, we call pci_register_root_bus()
in the device's instance_init. This is a problem for two reasons
* the PCI bridge is then available to the rest of the simulation
(e.g. via pci_qdev_find_device()), even though it hasn't
yet been realized
* we do not attempt to unregister in an instance_deinit,
which means that if you go through an instance_init -> deinit
lifecycle the freed memory for the host-bridge device is
left on the pci_host_bridges list
ASAN reports the resulting use-after-free:
==1771223==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000018f80 at pc 0x5b4b9d3369b5 bp 0x7ffd01929980 sp 0x7ffd01929978
WRITE of size 8 at 0x527000018f80 thread T0
#0 0x5b4b9d3369b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5
#1 0x5b4b9d321566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5
#2 0x5b4b9d3215e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5
#3 0x5b4b9d321fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11
#4 0x5b4b9d390521 in dino_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/dino.c:473:16
0x527000018f80 is located 1664 bytes inside of 12384-byte region [0x527000018900,0x52700001b960)
freed by thread T0 here:
#0 0x5b4b9cab185a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140)
#1 0x5b4b9e3ee723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9
#2 0x5b4b9e3e69db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9
#3 0x5b4b9ea6173c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5
#4 0x5b4b9ec4e0f3 in qmp_marshal_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qapi/qapi-commands-qdev.c:65:14
previously allocated by thread T0 here:
#0 0x5b4b9cab1af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140)
#1 0x799d8270eb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5b4b9e3e75fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15
#3 0x5b4b9e3e7409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12
#4 0x5b4b9ea609a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11
where we allocated one instance of the dino device, put it on the
list, freed it, and then trying to allocate a second instance touches
the freed memory on the pci_host_bridges list.
Fix this by deferring all the setup of memory regions and registering
the PCI bridge to the device's realize method. This brings it into
line with almost all other PCI host bridges, which call
pci_register_root_bus() in realize.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Fixes: 63901b6cc4d8b4 ("dino: move PCI bus initialisation to dino_pcihost_init()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250918114259.1802337-2-peter.maydell@linaro.org>
(cherry picked from commit e4a1b308b27cd77338b8f05d3a31e6b38eb717c7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [12:5] are ignored for !imm.
For v8, those same bits are reserved, but are not trapped.
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit df663ac0a4e5d916b6b3e77552a925fec02bced4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: e8325dc02d0 ("target/sparc: Move RDTBR, FLUSHW to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 6ff52f9dee064d3c2138426834320f5877863d9b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: 5d617bfba07 ("target/sparc: Move RDWIM, RDPR to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit dc9678cc9725d6c3053c6f110f162d956eb9d48f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: 668bb9b755e ("target/sparc: Move RDPSR, RDHPR to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a0345f628394fbd001276c80fd02c8ad0d1b7ee2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bits [18:0] are not decoded with v7, and for v8 unused values
of rs1 simply produce undefined results.
Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
(cherry picked from commit 49d669ccf33a772e3baf3fe4ebb996dc015f46c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Solaris 8 appears to have a bug whereby it executes v9 MEMBAR
instructions when booting a freshly installed image. According
to the SPARC v8 architecture manual, whilst bits 13 and bits 12-0
of the "Read State Register Instructions" are notionally zero,
they are marked as unused (i.e. ignored).
Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3097 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
(cherry picked from commit b6cdd6c6050567c02a3b3cd428f85bb79d7455aa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/sparc: Allow TRANS macro with no extra arguments
Use ## to drop the preceding comma if __VA_ARGS__ is empty.
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit b7cd0a1821adf9906c5edb248394bb2a95482656) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Fri, 19 Sep 2025 08:20:54 +0000 (10:20 +0200)]
linux-user: avoid -Werror=int-in-bool-context
linux-user is failing to compile on Fedora 43:
../linux-user/strace.c:57:66: error: enum constant in boolean context [-Werror=int-in-bool-context]
57 | #define FLAG_BASIC(V, M, N) { V, M | QEMU_BUILD_BUG_ON_ZERO(!(M)), N }
The warning does not seem to be too useful and we could even disable it,
but the workaround is simple in this case.
Cc: qemu-stable@nongnu.org Cc: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit db05b0d21ec1e0532cf5f5103ae6520a838d96f9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
We can see that the instruction at 0x1e3 is a far jmp through the GDT.
However, the GDT is not 8 byte aligned, the base is 0xc02b4.
Intel processors follow the LOCK semantics to set the accessed flag of the
segment descriptor when loading a segment descriptor. If the the segment
descriptor crosses two cache line, it causes split lock.
Fix it by aligning the GDT on 8 bytes, so that segment descriptor cannot
span two cache lines.
Xiaoyao Li [Wed, 30 Jul 2025 09:52:53 +0000 (17:52 +0800)]
target/i386: Define enum X86ASIdx for x86's address spaces
Define X86ASIdx as enum, like ARM's ARMASIdx, so that it's clear index 0
is for memory and index 1 is for SMM.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-By: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 591f817d819f5511fd9001dc863a326d23088811)
(Mjt: pick this change for completness with the previous one) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Xiaoyao Li [Wed, 30 Jul 2025 09:52:52 +0000 (17:52 +0800)]
i386/cpu: Enable SMM cpu address space under KVM
Kirill Martynov reported assertation in cpu_asidx_from_attrs() being hit
when x86_cpu_dump_state() is called to dump the CPU state[*]. It happens
when the CPU is in SMM and KVM emulation failure due to misbehaving
guest.
The root cause is that QEMU i386 never enables the SMM address space for
cpu since KVM SMM support has been added.
Enable the SMM cpu address space under KVM when the SMM is enabled for
the x86machine.
hw/usb/network: Remove hardcoded 0x40 prefix in STRING_ETHADDR response
USB NICs have a "40:" prefix hardcoded for all MAC addresses when we
return the guest the MAC address if it queries the STRING_ETHADDR USB
string property. This doesn't match what we use for the
OID_802_3_PERMANENT_ADDRESS or OID_802_3_CURRENT_ADDRESS OIDs for
NDIS, or the MAC address we actually use in the QEMU networking code
to send/receive packets for this device, or the NIC info string we
print for users. In all those other places we directly use
s->conf.macaddr.a, which is the full thing the user asks for.
This overrides user-provided configuration and leads to an inconsistent
experience.
I couldn't find any documented reason (comment or git commits) for
this behavior. It seems like everyone is just expecting the MAC
address to be fully passed through to the guest, but it isn't.
This may have been a debugging hack that accidentally made it through
to the accepted patch: it has been in the code since it was originally
added back in 2008.
This is also particularly problematic as the "40:" prefix isn't a
reserved prefix for MAC addresses (IEEE OUI). There are a number of
valid allocations out there which use this prefix, meaning that QEMU
may be causing MAC address conflicts.
Cc: qemu-stable@nongnu.org Fixes: 6c9f886ceae5b ("Add CDC-Ethernet usb NIC (original patch from Thomas Sailer)" Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2951 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[PMM: beef up commit message based on mailing list discussion] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit aaf042299acf83919862c7d7dd5fc36acf4e0671) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 16 Jun 2025 16:56:49 +0000 (18:56 +0200)]
rust: hpet: fix new warning
Nightly rustc complains that HPETAddrDecode has a lifetime but it is not
clearly noted that it comes from &self. Apply the compiler's suggestion
to shut it up.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6b3fad084fc4e13901e252fe6c2a2c46ecea999b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 5 May 2025 14:23:26 +0000 (16:23 +0200)]
ci: run RISC-V cross jobs by default
The riscv64-debian-cross container is based on Trixie rather than sid
these days, so it is pretty much as stable as the others. Enable it
by default.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit eb8f7292e1315be0e36000a847b77153dcf460ef) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Mon, 8 Sep 2025 14:19:11 +0000 (15:19 +0100)]
.gitmodules: move u-boot mirrors to qemu-project-mirrors
To continue our GitLab Open Source Program license we need to pass an
automated license check for all repos under qemu-project. While U-Boot
is clearly GPLv2 rather than fight with the automated validation
script just move the mirror across to a separate project.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250908141911.2546063-1-alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a11d1847d5ef8a7db58e6d4e44f36fec708f0981) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Of most importance is that this gives us a heads-up if anything
we rely on has been deprecated. The default python behaviour
only emits a warning if triggered from __main__ which is very
limited.
Setting the env variable further ensures that any python child
processes will also display warnings.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 9a494d83538680651197651031375c2b6fa2490b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The iotest 151 creates a bunch of subprocesses, with their stdout
connected to a pipe but never reads any data from them and does
not gurantee the processes are killed on cleanup.
This triggers resource leak warnings from python when the
subprocess.Popen object is garbage collected.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 2b2fb25c2aaf5b2e8172d845db39cc50a951a12e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
iotests/147: ensure temporary sockets are closed before exiting
This avoids the python resource leak detector from issuing warnings
in the iotests.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit d4d0ebfcc926c11d16320d0d5accf22e3441c115) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
python: ensure QEMUQtestProtocol closes its socket
While QEMUQtestMachine closes the socket that was passed to
QEMUQtestProtocol, the python resource leak manager still
believes that the copy QEMUQtestProtocol holds is open. We
must explicitly call close to avoid this leak warnnig.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 6ccb48ffc19fe25511313a246d4a8bad51114ea9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
iotests: drop compat for old version context manager
Our minimum python is now 3.9, so back compat with prior
python versions is no longer required.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 82c7cb93c750196f513a1b11cb85e0328bad444f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Wed, 3 Sep 2025 05:06:30 +0000 (01:06 -0400)]
python: backport 'avoid creating additional event loops per thread'
This commit is two backports squashed into one to avoid regressions.
python: *really* remove get_event_loop
A prior commit, aa1ff990, switched away from using get_event_loop *by
default*, but this is not good enough to avoid deprecation warnings as
`asyncio.get_event_loop_policy().get_event_loop()` is *also*
deprecated. Replace this mechanism with explicit calls to
asyncio.get_new_loop() and revise the cleanup mechanisms in __del__ to
match.
python: avoid creating additional event loops per thread
"Too hasty by far!", commit 21ce2ee4 attempted to avoid deprecated
behavior altogether by calling new_event_loop() directly if there was no
loop currently running, but this has the unfortunate side effect of
potentially creating multiple event loops per thread if tests
instantiate multiple QMP connections in a single thread. This behavior
is apparently not well-defined and causes problems in some, but not all,
combinations of Python interpreter version and platform environment.
Partially revert to Daniel Berrange's original patch, which calls
get_event_loop and simply suppresses the deprecation warning in
Python<=3.13. This time, however, additionally register new loops
created with new_event_loop() so that future calls to get_event_loop()
will return the loop already created.
Reported-by: Richard W.M. Jones <rjones@redhat.com> Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@21ce2ee4f2df87efe84a27b9c5112487f4670622
cherry picked from commit python-qemu-qmp@c08fb82b38212956ccffc03fc6d015c3979f42fe Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 85f223e5b031eb8ab63fbca314a4fb296a3a2632) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This method was deprecated in 3.12 because it ordinarily should not be
used from coroutines; if there is not a currently running event loop,
this automatically creates a new event loop - which is usually not what
you want from code that would ever run in the bottom half.
In our case, we do want this behavior in two places:
(1) The synchronous shim, for convenience: this allows fully sync
programs to use QEMUMonitorProtocol() without needing to set up an event
loop beforehand. This is intentional to fully box in the async
complexities into the legacy sync shim.
(2) The qmp_tui shell; instead of relying on asyncio.run to create and
run an asyncio program, we need to be able to pass the current asyncio
loop to urwid setup functions. For convenience, again, we create one if
one is not present to simplify the creation of the TUI appliance.
The remaining user of get_event_loop() was in fact one of the erroneous
users that should not have been using this function: if there's no
running event loop inside of a coroutine, you're in big trouble :)
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@aa1ff9907603a3033296027e1bd021133df86ef1 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 5d99044d09db0fa8c2b3294e301927118f9effc9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Fri, 22 Jul 2022 19:55:45 +0000 (15:55 -0400)]
python: backport 'qmp-tui: Do not crash if optional dependencies are not met'
Based on the discussion at https://github.com/pypa/pip/issues/9726 -
even though the setuptools documentation implies that it is possible to
guard script execution with optional dependency groups, this is not true
in practice with the scripts generated by pip.
Just do the simple thing and guard the import statements.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@df520dcacf9a75dd4c82ab1129768de4128b554c Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit fd0ed46d4effbf2700804657bad9c6db086527c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@9c889dcbd58817b0c917a9d2dd16161f48ac8203 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit fcaeeb7653d2c6f38183170e1cae5729adb7875c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 6 Jun 2023 17:45:44 +0000 (13:45 -0400)]
python: backport 'Use @asynciocontextmanager'
This removes a non-idiomatic use of a "coroutine callback" in favor of
something a bit more standardized.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@commit 97f7ffa3be17a50544b52767d14b6fd478c07b9e Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 0408b8d7a086486f5c1887798be744b2d73bcda9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 6 Jun 2023 17:19:11 +0000 (13:19 -0400)]
python: backport 'drop Python3.6 workarounds'
Now that the minimum version is 3.7, drop some of the 3.6-specific hacks
we've been carrying. A single remaining compatibility hack concerning
3.6's lack of @asynccontextmanager is addressed in the following commit.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@3e8e34e594cfc6b707e6f67959166acde4b421b8 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit f9d2e0a3bd7ba2a693a892881f91cf53fa90cc71) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 3 May 2022 18:07:10 +0000 (14:07 -0400)]
python: backport 'kick event queue on legacy event_pull()'
This corrects an oversight in qmp-shell operation where new events will
not accumulate in the event queue when pressing "enter" with an empty
command buffer, so no new events show up.
Reported-by: Jag Raman <jag.raman@oracle.com> Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@0443582d16cf9efd52b2c41a7b5be7af42c856cd Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 1e343714bfc06cc982e68a290f3809117d6dfcd0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The required "id" is only set up automatically while parsing the command
line, but not when reading the options from the config file.
Thus let's move code that automatically adds the id (if it does not
exist yet) to the init function that needs the id for the first time,
replacing the assert() statement there.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2836 Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250821145130.845104-1-thuth@redhat.com>
(cherry picked from commit 38dd513263d814dc3cf554b899c118a46ca77577) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
WANG Rui [Fri, 25 Jul 2025 03:12:32 +0000 (11:12 +0800)]
target/loongarch: Guard 64-bit-only insn translation with TRANS64 macro
This patch replaces uses of the generic TRANS macro with TRANS64 for
instructions that are only valid when 64-bit support is available.
This improves correctness and avoids potential assertion failures or
undefined behavior during translation on 32-bit-only configurations.
Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 96e7448c1f820c56caea8447c01f5227b0c95c79) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
WANG Rui [Fri, 18 Apr 2025 08:21:01 +0000 (16:21 +0800)]
target/loongarch: Add CRC feature flag and use it to gate CRC instructions
This patch replaces the obsolete IOCSR_BRD bit with CRC in cpucfg1[25],
in both LA464 and LA132 CPU initialization functions. The corresponding
field macro in `cpu.h` is updated to reflect this change.
Additionally, the availability macro `avail_CRC()` is introduced in
`translate.h` to check the CRC feature flag.
All CRC-related instruction translations are updated to be gated by
the new CRC feature flag instead of hardcoded CPU features.
This ensures correctness and configurability when enabling CRC
instructions based on hardware capabilities.
Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20250418082103.447780-2-wangrui@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 256df51e727235b3d5e937ca2784c45663c00f59)
(Mjt: pick this one up for 10.0.x so subsequent changes applies cleanly) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Tokarev [Sun, 24 Aug 2025 00:05:32 +0000 (03:05 +0300)]
block/curl: fix curl internal handles handling
block/curl.c uses CURLMOPT_SOCKETFUNCTION to register a socket callback.
According to the documentation, this callback is called not just with
application-created sockets but also with internal curl sockets, - and
for such sockets, user data pointer is not set by the application, so
the result qemu crashing.
Pass BDRVCURLState directly to the callback function as user pointer,
instead of relying on CURLINFO_PRIVATE.
This problem started happening with update of libcurl from 8.9 to 8.10 --
apparently with this change curl started using private handles more.
(CURLINFO_PRIVATE is used in one more place, in curl_multi_check_completion() -
it might need a similar fix too)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3081 Cc: qemu-stable@qemu.org Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 606978500c3d18fb89a49844f253097b17f757de) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 21 Aug 2025 15:44:59 +0000 (16:44 +0100)]
hw/gpio/pca9554: Avoid leak in pca9554_set_pin()
In pca9554_set_pin() we have a string property which we parse in
order to set some non-string fields in the device state. So we call
visit_type_str(), passing it the address of the local variable
state_str.
visit_type_str() will allocate a new copy of the string; we
never free this string, so the result is a memory leak, detected
by ASAN during a "make check" run:
Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (
BuildId: 3d5373c89317f58bfcd191a33988c7347714be14)
#1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo
bject-input-visitor.c:542:12
#5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit
-core.c:349:10
#6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10
#7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5
#8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10
#9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15
#10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5
#11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9
Make the state_str g_autofree, so that we will always free
it, on both error-exit and success codepaths.
Cc: qemu-stable@nongnu.org Fixes: de0c7d543bca ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3284d1c07cfd8d42aa27d1cf83d3e65fcd62e35e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Aditya Gupta [Wed, 20 Aug 2025 12:25:17 +0000 (17:55 +0530)]
hw/ppc: Fix build error with CONFIG_POWERNV disabled
Currently when CONFIG_POWERNV is not enabled, the build fails, such as
with --without-default-devices:
$ ./configure --without-default-devices
$ make
[281/283] Linking target qemu-system-ppc64
FAILED: qemu-system-ppc64
cc -m64 @qemu-system-ppc64.rsp
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_load_sprd':
.../target/ppc/misc_helper.c:335:(.text+0xcdc): undefined reference to `pnv_chip_find_core'
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_store_sprd':
.../target/ppc/misc_helper.c:375:(.text+0xdf4): undefined reference to `pnv_chip_find_core'
collect2: error: ld returned 1 exit status
...
This is since target/ppc/misc_helper.c references PowerNV specific
'pnv_chip_find_core' call.
Split the PowerNV specific SPRD code out of the generic PowerPC code, by
moving the SPRD code to pnv.c
Fixes: 9808ce6d5cb ("target/ppc: Big-core scratch register fix") Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Acked-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20250820122516.949766-2-adityag@linux.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 46d03bb23dde86513465724760d85f42eb17539e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis Rastyogin [Thu, 14 Aug 2025 10:48:32 +0000 (13:48 +0300)]
target/mips: fix TLB huge page check to use 64-bit shift
Use extract64(entry, psn, 1) instead of (entry & (1 << psn)) to avoid
undefined behavior for shifts by 32–63 and to make bit extraction intent explicit.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Rastyogin <gerben@altlinux.org>
Message-ID: <20250814104914.13101-1-gerben@altlinux.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1f82ca723478f44823a18e7151e487d58da03659) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select M14Kc CPU to run microMIPS binaries
The M14Kc is our latest CPU supporting the microMIPS ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting microMIPS ASE.
Cc: qemu-stable@nongnu.org Fixes: 3c824109da0 ("target-mips: microMIPS ASE support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-4-philmd@linaro.org>
(cherry picked from commit 51c3aebfda6489b49cebef593a1ceb597cb97a7e)
(Mjt: in 10.1 and before, the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select 74Kf CPU to run MIPS16e binaries
The 74Kf is our latest CPU supporting MIPS16e ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting MIPS16e ASE.
Cc: qemu-stable@nongnu.org Fixes: 6ea219d0196..d19954f46df ("target-mips: MIPS16 support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-3-philmd@linaro.org>
(cherry picked from commit 7a09b3cc70ab6d717b18dec5c5995f7a06af4593)
(Mjt: in 10.1 and before the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Include MIPS ASE ELF definitions from binutils:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/mips.h;h=4fc190f404d828ded84e621bfcece5fa9f9c23c8;hb=HEAD#l210
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-2-philmd@linaro.org>
(cherry picked from commit 14ab44b96d5bf761af81cc723314ef5ecf73ed17) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Laurent Vivier [Thu, 7 Aug 2025 11:08:06 +0000 (13:08 +0200)]
e1000e: Prevent crash from legacy interrupt firing after MSI-X enable
A race condition between guest driver actions and QEMU timers can lead
to an assertion failure when the guest switches the e1000e from legacy
interrupt mode to MSI-X. If a legacy interrupt delay timer (TIDV or
RDTR) is active, but the guest enables MSI-X before the timer fires,
the pending interrupt cause can trigger an assert in
e1000e_intmgr_collect_delayed_causes().
This patch removes the assertion and executes the code that clears the
pending legacy causes. This change is safe and introduces no unintended
behavioral side effects, as it only alters a state that previously led
to termination.
- when core->delayed_causes == 0 the function was already a no-op and
remains so.
- when core->delayed_causes != 0 the function would previously
crash due to the assertion failure. The patch now defines a safe
outcome by clearing the cause and returning. Since behavior after
the assertion never existed, this simply corrects the crash.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1863 Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250807110806.409065-1-lvivier@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 8e4649cac9bcddc050d2df07908075e9e69bccc7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
vfio scsi ui: Error-check qio_channel_socket_connect_sync() the same way
qio_channel_socket_connect_sync() returns 0 on success, and -1 on
failure, with errp set. Some callers check the return value, and some
check whether errp was set.
For consistency, always check the return value, and always check it's
negative.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-3-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit ec14a3de622ae30a8afa78b6f564bc743b753ee1)
(Mjt: drop changes for hw/vfio-user/proxy.c which is not in 10.0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
i386/kvm/vmsr_energy: Plug memory leak on failure to connect socket
vmsr_open_socket() leaks the Error set by
qio_channel_socket_connect_sync(). Plug the leak by not creating the
Error.
Fixes: 0418f90809ae (Add support for RAPL MSRs in KVM/Qemu) Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-2-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit b2e4534a2c9ce3d20ba44d855f1e2b71cc53c3a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
QGA-VSS writes error using error_setg_win32_internal,
which call g_win32_error_message.
g_win32_error_message - translate a Win32 error code
(as returned by GetLastError()) into the corresponding message.
In the same time, we call error_setg_win32_internal with
error codes from different Windows componets like VSS or
Performance monitor that provides different codes and
can't be converted with g_win32_error_message. In this
case, the empty suffix will be returned so error will be
masked.
This commit directly add hex value of error code.
Reproduce:
- Run QGA command: {"execute": "guest-fsfreeze-freeze-list", "arguments": {"mountpoints": ["D:"]}}
QGA error example:
- before changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: "}}
- after changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: Windows error 0x8004230e: "}}
qga/installer: Remove QGA VSS if QGA installation failed
When QGA Installer failed to install QGA service but install
QGA VSS provider, provider should be removed before installer
exits. Otherwise QGA VSS will has broken infomation and
prevent QGA installation in next run.
In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we call object_new() and then later qdev_realize(),
and we never unref the object on deinit. This causes a leak,
detected by ASAN on the device-introspect-test:
Indirect leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe)
#1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18
#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12
#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10
#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12
#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9
#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5
#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5
#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9
#12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5
#13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5
#14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26
Switch to using object_initialize_child() like all our
other child objects for this SoC object.
Cc: qemu-stable@nongnu.org Fixes: b63041c8f6b ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org
(cherry picked from commit 2e27650bddd35477d994a795a3b1cb57c8ed5c76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Tue, 19 Aug 2025 11:56:48 +0000 (12:56 +0100)]
scripts/kernel-doc: Avoid new Perl precedence warning
Newer versions of Perl (5.41.x and up) emit a warning for code in
kernel-doc:
Possible precedence problem between ! and pattern match (m//) at /scripts/kernel-doc line 1597.
This is because the code does:
if (!$param =~ /\w\.\.\.$/) {
In Perl, the ! operator has higher precedence than the =~
pattern-match binding, so the effect of this condition is to first
logically-negate the string $param into a true-or-false value and
then try to pattern match it against the regex, which in this case
will always fail. This is almost certainly not what the author
intended.
In the new Python version of kernel-doc in the Linux kernel,
the equivalent code is written:
if KernRe(r'\w\.\.\.$').search(param):
# For named variable parameters of the form `x...`,
# remove the dots
param = param[:-3]
else:
# Handles unnamed variable parameters
param = "..."
which is a more sensible way of writing the behaviour you would
get if you put in brackets to make the regex match first and
then negate the result.
Take this as the intended behaviour, and update the Perl to match.
For QEMU, this produces no change in output, presumably because we
never used the "unnamed variable parameters" syntax.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Message-id: 20250819115648.2125709-1-peter.maydell@linaro.org
(cherry picked from commit 5ffd387e9e0f787744fadaad35e1bf92224b0642) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Smail AIDER [Tue, 26 Aug 2025 10:21:28 +0000 (11:21 +0100)]
target/arm: Trap PMCR when MDCR_EL2.TPMCR is set
Trap PMCR_EL0 or PMCR accesses to EL2 when MDCR_EL2.TPMCR is set.
Similar to MDCR_EL2.TPM, MDCR_EL2.TPMCR allows trapping EL0 and EL1
accesses to the PMCR register to EL2.
Cc: qemu-stable@nongnu.org Signed-off-by: Smail AIDER <smail.aider@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250811112143.1577055-2-smail.aider@huawei.com
Message-Id: <20250722131925.2119169-1-smail.aider@huawei.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 186db6a73bc5c01026bb9f4f4a59e442c0156841)
(Mjt: adjust for 10.0, before target/arm/helper.c split) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Steve Sistare [Tue, 26 Aug 2025 10:21:28 +0000 (11:21 +0100)]
hw/intc/arm_gicv3_kvm: preserve pending interrupts during cpr
Close a race condition that causes cpr-transfer to lose VFIO
interrupts on ARM.
CPR stops VCPUs but does not disable VFIO interrupts, which may continue
to arrive throughout the transition to new QEMU.
CPR calls kvm_irqchip_remove_irqfd_notifier_gsi in old QEMU to force
future interrupts to the producer eventfd, where they are preserved.
Old QEMU then destroys the old KVM instance. However, interrupts may
already be pending in KVM state. To preserve them, call ioctl
KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES to flush them to guest RAM, where
they will be picked up when the new KVM+VCPU instance is created.
Cc: qemu-stable@nongnu.org Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-id: 1754936384-278328-1-git-send-email-steven.sistare@oracle.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 376cdd7e9c94f1e03b2c58e068e8ebfe78b49514) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250826060341.1118670-1-joel@jms.id.au>
(cherry picked from commit f91563d011a0439cd6709e169cdfac268779d562) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Zero Tang [Mon, 18 Aug 2025 10:16:47 +0000 (12:16 +0200)]
i386/tcg/svm: fix incorrect canonicalization
For all 32-bit systems and 64-bit Windows systems, "long" is 4 bytes long.
Due to using "long" for a linear address, svm_canonicalization would
set all high bits to 1 when (assuming 48-bit linear address) the segment
base is bigger than 0x7FFF.
This fixes booting guests under TCG when the guest IDT and GDT bases are
above 0x7FFF, thereby resulting in incorrect bases. When an interrupt
arrives, it would trigger a #PF exception; the #PF would trigger again,
resulting in a #DF exception; the #PF would trigger for the third time,
resulting in triple-fault, and eventually causes a shutdown VM-Exit to
the hypervisor right after guest boot.
Cc: qemu-stable@nongnu.org Signed-off-by: Zero Tang <zero.tangptr@gmail.com>
(cherry picked from commit c12cbaa007c9da97a11e74119ea3aed9fcc3ac4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Gerd Hoffmann [Mon, 11 Aug 2025 13:01:09 +0000 (15:01 +0200)]
hw/uefi: check access for first variable
When listing variables (via get-next-variable-name) only the names of
variables which can be accessed will be returned. That check was
missing for the first variable though. Add it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20250811130110.820958-3-kraxel@redhat.com>
(cherry picked from commit fc8ee8fe58ad410f27fca64e4ad212c5a3eabe00) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/uefi: clear uefi-vars buffer in uefi_vars_write callback
When the guest writes to register UEFI_VARS_REG_BUFFER_SIZE, the .write
callback `uefi_vars_write` is invoked. The function allocates a
heap buffer without zeroing the memory, leaving the buffer filled with
residual data from prior allocations. When the guest later reads from
register UEFI_VARS_REG_PIO_BUFFER_TRANSFER, the .read callback
`uefi_vars_read` returns leftover metadata or other sensitive process
memory from the previously allocated buffer, leading to an information
disclosure vulnerability.
Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
[Edits: Type "safety" whackamole --js] Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20250811190159.237321-1-jsnow@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 6ad034e71232c2929ed546304c9d249312bb632f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/sd/ssi-sd: Return noise (dummy byte) when no card connected
Commit 1585ab9f1ba ("hw/sd/sdcard: Fill SPI response bits in card
code") exposed a bug in the SPI adapter: if no SD card is plugged,
we are returning "there is a card with an error". This is wrong,
we shouldn't return any particular packet response, but the noise
shifted on the MISO line. Return the dummy byte, otherwise we get:
Werner Fink [Wed, 6 Aug 2025 06:54:51 +0000 (08:54 +0200)]
qemu-iotests: Ignore indentation in Killed messages
New bash 5.3 uses a different padding for reporting job status.
Resolves: boo#1246830
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3050 Signed-off-by: Werner Fink <werner@suse.de>
Message-ID: <aJL8RH8ePPNEteMg@boole.nue2.suse.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c0df98ab1f3d348bc05f09d1c093abc529f2b530) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Mon, 11 Aug 2025 13:40:10 +0000 (15:40 +0200)]
rbd: Fix .bdrv_get_specific_info implementation
qemu_rbd_get_specific_info() has at least two problems:
The first is that it issues a blocking rbd_read() call in order to probe
the encryption format for the image while querying the node. This means
that if the connection to the server goes down, not only I/O is stuck
(which is unavoidable), but query-names-block-nodes will actually make
the whole QEMU instance unresponsive. .bdrv_get_specific_info
implementations shouldn't perform blocking operations, but only return
what is already known.
The second is that the information returned isn't even correct. If the
image is already opened with encryption enabled at the RBD level, we'll
probe for "double encryption", i.e. if the encrypted data contains
another encryption header. If it doesn't (which is the normal case), we
won't return the encryption format. If it does, we return misleading
information because it looks like we're talking about the outer level
(the encryption format of the image itself) while the information is
about an encryption header in the guest data.
Fix this by storing the encryption format in BDRVRBDState when the image
is opened (and we do blocking operations anyway) and returning only the
stored information in qemu_rbd_get_specific_info().
The information we'll store is either the actual encryption format that
we enabled on the RBD level, or if the image is unencrypted, the result
of the same probing as we previously did when querying the node. Probing
image formats based on content that can be modified by the guest has
long been known as problematic, but as long as we only output it to the
user instead of making decisions based on it, it should be okay. It is
undoubtedly useful in the context of 'qemu-img info' when you're trying
to figure out which encryption options you have to use to open the
image successfully.
Fixes: 42e4ac9ef5a6 ("block/rbd: Add support for rbd image encryption") Buglink: https://issues.redhat.com/browse/RHEL-105440 Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811134010.81787-1-kwolf@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 4af976ef398e4e823addc00bf1c58787ba4952fe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Keith Busch [Fri, 1 Aug 2025 14:24:57 +0000 (07:24 -0700)]
hw/nvme: cap MDTS value for internal limitation
The emulated device had let the user set whatever max transfers size
they wanted, including no limit. However the device does have an
internal limit of 1024 segments. NVMe doesn't report max segments,
though. This is implicitly inferred based on the MDTS and MPSMIN values.
IOV_MAX is currently 1024 which 4k PRPs can exceed with 2MB transfers.
Don't allow MDTS values that can exceed this, otherwise users risk
seeing "internal error" status to their otherwise protocol compliant
commands.
Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 53493c1f836f4dda90a6b5f2fb3d9264918c6871) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Klaus Jensen [Tue, 3 Jun 2025 12:59:06 +0000 (14:59 +0200)]
hw/nvme: revert CMIC behavior
Commit cd59f50ab017 ("hw/nvme: always initialize a subsystem") causes
the controller to always set the CMIC.MCTRS ("Multiple Controllers")
bit. While spec-compliant, this is a deviation from the previous
behavior where this was only set if an nvme-subsys device was explicitly
created (to configure a subsystem with multiple controllers/namespaces).
Revert the behavior to only set CMIC.MCTRS if an nvme-subsys device is
created explicitly.
Reported-by: Alan Adamson <alan.adamson@oracle.com> Fixes: cd59f50ab017 ("hw/nvme: always initialize a subsystem") Reviewed-by: Alan Adamson <alan.adamson@oracle.com> Tested-by: Alan Adamson <alan.adamson@oracle.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit bc0c24fdb157b014932a5012fe4ccbeba7617f17) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
According to the specification, [X]VLDI should trigger an invalid instruction
exception only when Bit[12] is 1 and Bit[11:8] > 12. This patch fixes an issue
where an exception was incorrectly raised even when Bit[12] was 0.
Test case:
```
.global main
main:
vldi $vr0, 3328
ret
```
Reported-by: Zhou Qiankang <wszqkzqk@qq.com> Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250804132212.4816-1-wangrui@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit e66644c48e96e81848c6aa94b185f59fc212d080) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Glenn Miles [Mon, 12 May 2025 03:10:19 +0000 (13:10 +1000)]
ppc/xive2: Fix treatment of PIPR in CPPR update
According to the XIVE spec, updating the CPPR should also update the
PIPR. The final value of the PIPR depends on other factors, but it
should never be set to a value that is above the CPPR.
Also added support for redistributing an active group interrupt when it
is precluded as a result of changing the CPPR value.
Signed-off-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-11-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit d4720a7faf4bb415f3fe7f10e5c888212b81316a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Glenn Miles [Mon, 12 May 2025 03:10:18 +0000 (13:10 +1000)]
ppc/xive2: Fix irq preempted by lower priority group irq
A problem was seen where uart interrupts would be lost resulting in the
console hanging. Traces showed that a lower priority interrupt was
preempting a higher priority interrupt, which would result in the higher
priority interrupt never being handled.
The new interrupt's priority was being compared against the CPPR
(Current Processor Priority Register) instead of the PIPR (Post
Interrupt Priority Register), as was required by the XIVE spec.
This allowed for a window between raising an interrupt and ACK'ing
the interrupt where a lower priority interrupt could slip in.
Fixes: 26c55b99418 ("ppc/xive2: Process group backlog when updating the CPPR") Signed-off-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-10-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 8d373176181fbc11f8d8eae2b4532b867f083ea6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Kowal [Mon, 12 May 2025 03:10:16 +0000 (13:10 +1000)]
ppc/xive2: Reset Generation Flipped bit on END Cache Watch
When the END Event Queue wraps the END EQ Generation bit is flipped and the
Generation Flipped bit is set to one. On a END cache Watch read operation,
the Generation Flipped bit needs to be reset.
While debugging an error modified END not valid error messages to include
the method since all were the same.
Signed-off-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-8-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 576830428eea6ebfc85792851a343214b834e401) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Mon, 12 May 2025 03:10:15 +0000 (13:10 +1000)]
ppc/xive: Fix PHYS NSR ring matching
Test that the NSR exception bit field is equal to the pool ring value,
rather than any common bits set, which is more correct (although there
is no practical bug because the LSI NSR type is not implemented and
POOL/PHYS NSR are encoded with exclusive bits).
Fixes: 4c3ccac636 ("pnv/xive: Add special handling for pool targets") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-7-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit bde8c148bb22b99cb84cda800fa555851b8cb358) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Nicholas Piggin [Mon, 12 May 2025 03:10:14 +0000 (13:10 +1000)]
ppc/xive2: fix context push calculation of IPB priority
Pushing a context and loading IPB from NVP is defined to merge ('or')
that IPB into the TIMA IPB register. PIPR should therefore be calculated
based on the final IPB value, not just the NVP value.
Fixes: 9d2b6058c5b ("ppc/xive2: Add grouping level to notification") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-6-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit d1023a296c8297454fc4b207d58707c0a5e62e0a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Kowal [Mon, 12 May 2025 03:10:13 +0000 (13:10 +1000)]
ppc/xive2: Remote VSDs need to match on forwarding address
In a multi chip environment there will be remote/forwarded VSDs. The check
to find a matching INT controller (XIVE) of the remote block number was
checking the INTs chip number. Block numbers are not tied to a chip number.
The matching remote INT is the one that matches the forwarded VSD address
with VSD types associated MMIO BAR.
Signed-off-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-5-npiggin@gmail.com
[ clg: Fixed log format in pnv_xive2_get_remote() ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit e8cf73b849879cd93b1d1b5fd3bde79fb42064dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Glenn Miles [Mon, 12 May 2025 03:10:12 +0000 (13:10 +1000)]
ppc/xive2: Fix calculation of END queue sizes
The queue size of an Event Notification Descriptor (END)
is determined by the 'cl' and QsZ fields of the END.
If the cl field is 1, then the queue size (in bytes) will
be the size of a cache line 128B * 2^QsZ and QsZ is limited
to 4. Otherwise, it will be 4096B * 2^QsZ with QsZ limited
to 12.
Fixes: f8a233dedf2 ("ppc/xive2: Introduce a XIVE2 core framework") Signed-off-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Michael Kowal <kowal@linux.ibm.com> Reviewed-by: Caleb Schlossin <calebs@linux.ibm.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250512031100.439842-4-npiggin@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit f16697292add6c3c15014a20fd5fce70b8c56734) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Zhao Liu [Mon, 4 Aug 2025 05:35:48 +0000 (13:35 +0800)]
target/i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]
Currently, the addressable ID encoding for CPUID[0x1].EBX[bits 16-23]
(Maximum number of addressable IDs for logical processors in this
physical package) is covered by vendor_cpuid_only_v2 compat property.
The previous consideration was to avoid breaking migration and this
compat property makes it unfriendly to backport the commit f985a1195ba2
("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX
[23:16]").
However, NetBSD booting is broken since the commit 88dd4ca06c83
("i386/cpu: Use APIC ID info to encode cache topo in CPUID[4]"),
because NetBSD calculates smt information via `lp_max` / `core_max` for
legacy Intel CPUs which doesn't support 0xb leaf, where `lp_max` is from
CPUID[0x1].EBX.bits[16-23] and `core_max` is from CPUID[0x4].0x0.bits[26
-31].
The commit 88dd4ca0 changed the encoding rule of `core_max` but didn't
update `lp_max`, so that NetBSD would get the wrong smt information,
which leads to the module loading failure.
Luckily, the commit f985a1195ba2 ("i386/cpu: Fix number of addressable
IDs field for CPUID.01H.EBX[23:16]") updated the encoding rule for
`lp_max` and accidentally fixed the NetBSD issue too. This also shows
that using CPUID[0x1] and CPUID[0x4].0x0 to calculate HT/SMT information
is a common practice to detect CPU topology on legacy Intel CPUs.
Therefore, it's necessary to backport the commit f985a1195ba2 to
previous stable QEMU to help address the similar issues as well. Then
the compat property is not needed any more since all stable QEMUs will
follow the same encoding way.
So, in CPUID[0x1], move addressable ID encoding out of compat property.
Reported-by: Michael Tokarev <mjt@tls.msk.ru> Inspired-by: Chuang Xu <xuchuangxclwt@bytedance.com> Fixes: commit f985a1195ba2 ("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3061 Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250804053548.1808629-1-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 4e5d58969ed6927a7f1b08ba6223c34c8b990c92)
(Mjt: when picking up commit f985a1195ba2d9c6f6f33e83fe2e419a7e8acb60
"i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]"
to 10.0, I commented out the condition (vendor_cpuid_only_v2 comparison)
which is now being removed) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
The legacy topology enumerated by CPUID.1.EBX[23:16] is defined in SDM
Vol2:
Bits 23-16: Maximum number of addressable IDs for logical processors in
this physical package.
When threads_per_socket > 255, it will 1) overwrite bits[31:24] which is
apic_id, 2) bits [23:16] get truncated.
Specifically, if launching the VM with -smp 256, the value written to
EBX[23:16] is 0 because of data overflow. If the guest only supports
legacy topology, without V2 Extended Topology enumerated by CPUID.0x1f
or Extended Topology enumerated by CPUID.0x0b to support over 255 CPUs,
the return of the kernel invoking cpu_smt_allowed() is false and APs
(application processors) will fail to bring up. Then only CPU 0 is online,
and others are offline.
For example, launch VM via:
qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split \
-cpu qemu64,cpuid-0xb=off -smp 256 -m 32G \
-drive file=guest.img,if=none,id=virtio-disk0,format=raw \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=1 --nographic
i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]
When QEMU is started with:
-cpu host,migratable=on,host-cache-info=on,l3-cache=off
-smp 180,sockets=2,dies=1,cores=45,threads=2
On Intel platform:
CPUID.01H.EBX[23:16] is defined as "max number of addressable IDs for
logical processors in the physical package".
When executing "cpuid -1 -l 1 -r" in the guest, we obtain a value of 90 for
CPUID.01H.EBX[23:16], whereas the expected value is 128. Additionally,
executing "cpuid -1 -l 4 -r" in the guest yields a value of 63 for
CPUID.04H.EAX[31:26], which matches the expected result.
As (1+CPUID.04H.EAX[31:26]) rounds up to the nearest power-of-2 integer,
it's necessary to round up CPUID.01H.EBX[23:16] to the nearest power-of-2
integer too. Otherwise there would be unexpected results in guest with
older kernel.
For example, when QEMU is started with CLI above and xtopology is disabled,
guest kernel 5.15.120 uses CPUID.01H.EBX[23:16]/(1+CPUID.04H.EAX[31:26]) to
calculate threads-per-core in detect_ht(). Then guest will get "90/(1+63)=1"
as the result, even though threads-per-core should actually be 2.
And on AMD platform:
CPUID.01H.EBX[23:16] is defined as "Logical processor count". Current
result meets our expectation.
So round up CPUID.01H.EBX[23:16] to the nearest power-of-2 integer only
for Intel platform to solve the unexpected result.
Use the "x-vendor-cpuid-only-v2" compat option to fix this issue.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com> Signed-off-by: Yipeng Yin <yinyipeng@bytedance.com> Signed-off-by: Chuang Xu <xuchuangxclwt@bytedance.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250714080859.1960104-5-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit f985a1195ba2d9c6f6f33e83fe2e419a7e8acb60)
(Mjt: this change refers to cpu->vendor_cpuid_only_v2 which is introduced
after 10.0, but this reference is removed later. Replace it with false
for now, so effectively this commit is a no-op, but prepares the code
for the next change in this area and keeps historical references) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Xiaoyao Li [Tue, 4 Mar 2025 05:24:49 +0000 (00:24 -0500)]
i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check
There is one entry relates to CPUID_EXT_PDCM in feature_dependencies[].
So it needs to get correct value of CPUID_EXT_PDCM before using
feature_dependencies[] to apply dependencies.
Besides, it also ensures CPUID_EXT_PDCM value is tracked in
env->features[FEAT_1_ECX].
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250304052450.465445-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit e68ec2980901c8e7f948f3305770962806c53f0b)
(Mjt: this simple cleanup is not strictly necessary for 10.0,
but pick it up so subsequent changes in this area applies cleanly) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Since more changes from the master branch are needed in the areas
which are being touched by this one, and this change has been
modified to apply without the previous commit(s), let's revert it
for now, apply previous patches, and re-apply it without modifications
on top.
Additionally, when I cherry-picked a62fef58299562aa, it somehow lost
its original authorship (Qian Wen). So this revert fixes both issues.
Michael Tokarev [Fri, 1 Aug 2025 11:53:14 +0000 (14:53 +0300)]
qga: correctly write to /sys/power/state on linux
Commit v9.0.0-343-g2048129625 introduced usage of
g_file_set_contents() function to write to /sys/power/state.
This function uses G_FILE_SET_CONTENTS_CONSISTENT flag to
g_file_set_contents_full(), which is implemented by creating
a temp file in the same directory and renaming it to the final
destination. Which is not how sysfs works.
Here, there's not a big deal to do open/write/close - it becomes
almost the same as using g_file_set_contents[_full](). But it
does not have surprises like this.
Also, since this is linux code, it should be ok to use %m in
the error reporting function.
Fixes: 2048129625 "qga/commands-posix: don't do fork()/exec() when suspending via sysfs"
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3057 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250801115316.6845-1-mjt@tls.msk.ru> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit b217d987a3c5c6e2473956723b396bc1ff0f5b2b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 21 Jul 2025 15:33:41 +0000 (16:33 +0100)]
scripts/make-release: Go back to cloning all the EDK2 submodules
In commit bd0da3a3d4f we changed make-release so that instead of
cloning every git submodule of EDK2 we only cloned a fixed list.
The original motivation for this was that one of the submodules:
* was from a non-github repo
* that repo had a "SSL certificate expired" failure
* wasn't actually needed for the set of EDK2 binaries we build
and at the time we were trying to build the EDK2 binaries in one of
our CI jobs.
Unfortunately this change meant that we were exposed to bugs where
EDK2 adds a new submodule and the sources we ship in the release
tarball won't build any more. In particular, in EDK2 commit c6bb7d54beb05 the MipiSysTLib submodule was added, causing failure of
the ROM build in our tarball starting from QEMU release 8.2.0:
/tmp/qemu-10.0.0/roms/edk2/MdePkg/MdePkg.dec(32): error 000E: File/directory not found in workspace
Library/MipiSysTLib/mipisyst/library/include is not found in packages path:
/tmp/qemu-10.0.0/roms/.
/tmp/qemu-10.0.0/roms/edk2
(Building from a QEMU git checkout works fine.)
In the intervening time EDK2 moved the submodule that had a problem
to be one they mirrored themselves (and at time of writing all their
submodules are hosted on github), and we stopped trying to build
EDK2 binaries in our own CI jobs with commit 690ceb71936f9037f6.
Go back to cloning every EDK2 submodule, so we don't have an
untested explicit list of submodules which will break without
our noticing it.
This increases the size of the QEMU tarball .tar.xz file from
133M to 139M in my testing.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3041 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250721153341.2910800-1-peter.maydell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit 0311a6edb9db34a41a2662d94c37e1fbaabf6ecf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Richardson [Fri, 25 Jul 2025 17:01:36 +0000 (10:01 -0700)]
target/arm: add support for 64-bit PMCCNTR in AArch32 mode
In the PMUv3, a new AArch32 64-bit (MCRR/MRRC) accessor for the
PMCCNTR was added. In QEMU we forgot to implement this, so only
provide the 32-bit accessor. Since we have a 64-bit PMCCNTR
sysreg for AArch64, adding the 64-bit AArch32 version is easy.
We add the PMCCNTR to the v8_cp_reginfo because PMUv3 was added
in the ARMv8 architecture. This is consistent with how we
handle the existing PMCCNTR support, where we always implement
it for all v7 CPUs. This is arguably something we should
clean up so it is gated on ARM_FEATURE_PMU and/or an ID
register check for the relevant PMU version, but we should
do that as its own tidyup rather than being inconsistent between
this PMCCNTR accessor and the others.
Since the register name is the same as the 32-bit PMCCNTR, we set
ARM_CP_NO_GDB on the 32-bit one to avoid generating an invalid GDB XML.
See https://developer.arm.com/documentation/ddi0601/2024-06/AArch32-Registers/PMCCNTR--Performance-Monitors-Cycle-Count-Register?lang=en
Note for potential backporting:
* this code in cpregs-pmu.c will be in helper.c on stable
branches that don't have commit ae2086426d37
Cc: qemu-stable@nongnu.org Signed-off-by: Alex Richardson <alexrichardson@google.com>
Message-id: 20250725170136.145116-1-alexrichardson@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit cd9f752fee75238f842a91be1146c988bd16a010)
(Mjt: moved code to target/arm/helper.c and modified it for 10.0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jamin Lin [Mon, 4 Aug 2025 01:46:33 +0000 (09:46 +0800)]
hw/ssi/aspeed_smc: Fix incorrect FMC_WDT2 register read on AST1030
On AST1030, reading the FMC_WDT2 register always returns 0xFFFFFFFF.
This issue is due to the aspeed_smc_read function, which checks for the
ASPEED_SMC_FEATURE_WDT_CONTROL feature. Since AST1030 was missing this
feature flag, the read operation fails and returns -1.
To resolve this, add the WDT_CONTROL feature to AST1030's feature set
so that FMC_WDT2 can be correctly accessed by firmware.
target/arm: Fix handling of setting SVE registers from gdb
The code to handle setting SVE registers via the gdbstub is broken:
* it sets each pair of elements in the zregs[].d[] array in the
wrong order for the most common (little endian) case: the least
significant 64-bit value comes first
* it makes no attempt to handle target_endian()
* it does a simple copy out of the (target endian) gdbstub buffer
into the (host endan) zregs data structure, which is wrong on
big endian hosts
Fix all these problems:
* use ldq_p() to read from the gdbstub buffer
* check target_big_endian() to see if we need to handle the
128-bit values the opposite way around
Cc: qemu-stable@nongnu.org Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com>
Message-id: 20250722173736.2332529-3-vacha.bhavsar@oss.qualcomm.com
[PMM: adjusted commit message, fixed spacing] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 97b3d732afec9b165c33697452e31267a845338f)
(Mjt: s/target_big_endian/target_words_bigendian/ due to missing v10.0.0-277-gb939b8e42a "exec: Rename target_words_bigendian() -> target_big_endian()") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/arm: Fix big-endian handling of NEON gdb remote debugging
In the code for allowing the gdbstub to set the value of an AArch64
FP/SIMD register, we weren't accounting for target_big_endian()
being true. This meant that for aarch64_be-linux-user we would
set the two halves of the FP register the wrong way around.
The much more common case of a little-endian guest is not affected;
nor are big-endian hosts.
Correct the handling of this case.
Cc: qemu-stable@nongnu.org Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com>
Message-id: 20250722173736.2332529-2-vacha.bhavsar@oss.qualcomm.com
[PMM: added comment, expanded commit message, fixed missing space] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 35cca0f95ff5345f54c11d116efc8940a0dab8aa)
(Mjt: s/target_big_endian/target_words_bigendian/ due to missing v10.0.0-277-gb939b8e42a "exec: Rename target_words_bigendian() -> target_big_endian()") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/intc/arm_gicv3_kvm: Write all 1's to clear enable/active
KVM's userspace access interface to the GICD enable and active bits
is via set/clear register pairs which implement the hardware's "write
1s to the clear register to clear the 0 bits, and write 1s to the set
register to set the 1 bits" semantics. We didn't get this right,
because we were writing 0 to the clear register.
Writing 0 to GICD_IC{ENABLE,ACTIVE}R architecturally has no effect on
interrupt status (all writes are simply ignored by KVM) and doesn't
comply with the intention of "first write to the clear-reg to clear
all bits".
Write all 1's to actually clear the enable/active status.
This didn't have any adverse effects on migration because there
we start with a clean VM state; it would be guest-visible when
doing a system reset, but since Linux always cleans up the
register state of the GIC during bootup before it enables it
most users won't have run into a problem here.
Cc: qemu-stable@nongnu.org Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Message-id: 20250729161650.43758-3-zenghui.yu@linux.dev Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b10bd4bd17ac8628ede8735a08ad82dc3b721c64) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Sairaj Kodilkar [Fri, 1 Aug 2025 06:05:04 +0000 (11:35 +0530)]
hw/i386/amd_iommu: Move IOAPIC memory region initialization to the end
Setting up IOAPIC memory region requires mr_sys and mr_ir. Currently
these two memory regions are setup after the initializing the IOAPIC
memory region, which cause `amdvi_host_dma_iommu()` to use unitialized
mr_sys and mr_ir.
Move the IOAPIC memory region initialization to the end in order to use
the mr_sys and mr_ir regions after they are fully initialized.
Fixes: 577c470f4326 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250801060507.3382-4-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a7842d94067cddc80b47ac42fb6e49e2fc02a3c5)
(Mjt: context fix due to missing v10.0.0-833-gf864a3235ea1
"hw/i386/amd_iommu: Isolate AMDVI-PCI from amd-iommu device
to allow full control over the PCI device creation") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
David Woodhouse [Mon, 14 Jul 2025 08:00:47 +0000 (09:00 +0100)]
intel_iommu: Allow both Status Write and Interrupt Flag in QI wait
FreeBSD does both, and this appears to be perfectly valid. The VT-d
spec even talks about the ordering (the status write should be done
first, unsurprisingly).
We certainly shouldn't assert() and abort QEMU if the guest asks for
both.
Fixes: ed7b8fbcfb88 ("intel-iommu: add supports for queued invalidation interface") Closes: https://gitlab.com/qemu-project/qemu/-/issues/3028 Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <0122cbabc0adcc3cf878f5fd7834d8f258c7a2f2.camel@infradead.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit e8145dcd311b58921f3a45121792cbfab38fd2f6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
pcie_sriov: Fix configuration and state synchronization
Fix issues in PCIe SR-IOV configuration register handling that caused
inconsistent internal state due to improper write mask handling and
incorrect migration behavior.
Two main problems were identified:
1. VF Enable bit write mask handling:
pcie_sriov_config_write() incorrectly assumed that its val parameter
was already masked, causing it to ignore the actual write mask.
This led to the VF Enable bit being processed even when masked,
resulting in incorrect VF registration/unregistration. It is
identified as CVE-2025-54567.
2. Migration state inconsistency:
pcie_sriov_pf_post_load() unconditionally called register_vfs()
regardless of the VF Enable bit state, creating inconsistent
internal state when VFs should not be enabled. Additionally,
it failed to properly update the NumVFs write mask based on
the current configuration. It is identified as CVE-2025-54566.
Root cause analysis revealed that both functions relied on incorrect
special-case assumptions instead of properly reading and consuming
the actual configuration values. This change introduces a unified
consume_config() function that reads actual configuration values and
synchronize the internal state without special-case assumptions.
The solution only adds register read overhead in non-hot-path code
while ensuring correct SR-IOV state management across configuration
writes and migration scenarios.
Fixes: 5e7dd17e4348 ("pcie_sriov: Remove num_vfs from PCIESriovPF") Fixes: f9efcd47110d ("pcie_sriov: Register VFs after migration") Fixes: CVE-2025-54566 Fixes: CVE-2025-54567 Cc: qemu-stable@nongnu.org Reported-by: Corentin BAYET <corentin.bayet@reversetactics.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-Id: <20250727-wmask-v2-1-394910b1c0b6@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cad9aa6fbdccd95e56e10cfa57c354a20a333717)
(Mjt: context fix) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The expected initial state of the table depends on feature negotiation:
With VIRTIO_NET_F_CTRL_VLAN:
The table must be empty in accordance with the specification.
Without VIRTIO_NET_F_CTRL_VLAN:
The table must be filled to permit all VLAN traffic.
Prior to commit 06b636a1e2ad ("virtio-net: do not reset vlan filtering
at set_features"), virtio_net_set_features() always reset the VLAN
table. That commit changed the behavior to skip table reset when
VIRTIO_NET_F_CTRL_VLAN was negotiated, assuming the table would be
properly cleared during device reset and remain stable.
However, this assumption breaks when a driver renegotiates features:
1. Initial negotiation without VIRTIO_NET_F_CTRL_VLAN (table filled)
2. Renegotiation with VIRTIO_NET_F_CTRL_VLAN (table will not be cleared)
The problem was exacerbated by commit 0caed25cd171 ("virtio: Call
set_features during reset"), which triggered virtio_net_set_features()
during device reset, exposing the bug whenever VIRTIO_NET_F_CTRL_VLAN
was negotiated after a device reset.
Solution
--------
Fix the issue by initializing the table when virtio_net_set_features()
is called to change the VIRTIO_NET_F_CTRL_VLAN bit of
vdev->guest_features.
This approach ensures the correct table state regardless of feature
negotiation sequence by performing initialization in
virtio_net_set_features() as QEMU did prior to commit 06b636a1e2ad
("virtio-net: do not reset vlan filtering at set_features").
This change still preserves the goal of the commit, which was to avoid
resetting the table during migration, by checking whether the
VIRTIO_NET_F_CTRL_VLAN bit of vdev->guest_features is being changed;
vdev->guest_features is set before virtio_net_set_features() gets called
during migration.
It also avoids resetting the table when the driver sets a feature
bitmask with no change for the VIRTIO_NET_F_CTRL_VLAN bit, which makes
the operation idempotent and its semantics cleaner.
Additionally, this change ensures the table is initialized after
feature negotiation and before the DRIVER_OK status bit being set for
compatibility with the Linux driver before commit 50c0ada627f5
("virtio-net: fix race between ndo_open() and virtio_device_ready()"),
which did not ensure to set the DRIVER_OK status bit before modifying
the table.
Fixes: 06b636a1e2ad ("virtio-net: do not reset vlan filtering at set_features") Cc: qemu-stable@nongnu.org Reported-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Tested-by: Lei Yang <leiyang@redhat.com>
Message-Id: <20250727-vlan-v3-1-bbee738619b1@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 6071d13c6a37493a6b26e1609b09a98aa058038a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Hanna Czenczek [Thu, 24 Jul 2025 12:59:28 +0000 (14:59 +0200)]
vhost: Do not abort on log-stop error
Failing to stop logging in a vhost device is not exactly fatal. We can
log such an error, but there is no need to abort the whole qemu process
because of it.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20250724125928.61045-3-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d63c388dadb7717f6391e1bb7f11728c0c1a3e36) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Hanna Czenczek [Thu, 24 Jul 2025 12:59:27 +0000 (14:59 +0200)]
vhost: Do not abort on log-start error
Commit 3688fec8923 ("memory: Add Error** argument to .log_global_start()
handler") enabled vhost_log_global_start() to return a proper error, but
did not change it to do so; instead, it still aborts the whole process
on error.
This crash can be reproduced by e.g. killing a virtiofsd daemon before
initiating migration. In such a case, qemu should not crash, but just
make the attempted migration fail.
Buglink: https://issues.redhat.com/browse/RHEL-94534 Reported-by: Tingting Mao <timao@redhat.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20250724125928.61045-2-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit c1997099dc26d95eb9f2249f2894aabf4cf0bf8b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
projects / thirdparty / qemu.git / log
