Branch: refs/heads/stable-9.2
Home: https://github.com/qemu/qemu
Commit: 361f29fe1bc6c847b108442d573fcd2690d6db4b
https://github.com/qemu/qemu/commit/361f29fe1bc6c847b108442d573fcd2690d6db4b
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M hw/9pfs/9p-util.h
Log Message:
-----------
9pfs: fix regression regarding CVE-2023-2861
The released fix for this CVE:
f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
caused a regression with security_model=passthrough. When handling a
'Tmknod' request there was a side effect that 'Tmknod' request could fail
as 9p server was trying to adjust permissions:
#6 close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140
#7 openat_file (mode=<optimized out>, flags=2228224,
name=<optimized out>, dirfd=<optimized out>) at
../hw/9pfs/9p-util.h:181
#8 fchmodat_nofollow (dirfd=dirfd@entry=31,
name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at
../hw/9pfs/9p-local.c:360
#9 local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0
"mysocket", dirfd=31, fs_ctx=0x55555811f528) at
../hw/9pfs/9p-local.c:457
#10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>,
name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at
../hw/9pfs/9p-local.c:702
#11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140,
fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0,
uid=1000, gid=1000, dev=<optimized out>, mode=49645,
stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205
#12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711
That's because server was opening the special file to adjust permissions,
however it was using O_PATH and it would have not returned the file
descriptor to guest. So the call to close_if_special_file() on that branch
was incorrect.
Let's lift the restriction introduced by f6b0de53fb8 such that it would
allow to open special files on host if O_PATH flag is supplied, not only
for 9p server's own operations as described above, but also for any client
'Topen' request.
It is safe to allow opening special files with O_PATH on host, because
O_PATH only allows path based operations on the resulting file descriptor
and prevents I/O such as read() and write() on that file descriptor.
Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337
Reported-by: Dirk Herrendorfer <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Tested-by: Dirk Herrendorfer <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f838a7e3659b1066e5b39be09b499d637d084758
https://github.com/qemu/qemu/commit/f838a7e3659b1066e5b39be09b499d637d084758
Author: Richard Henderson <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M accel/tcg/plugin-gen.c
M include/tcg/tcg-temp-internal.h
M tcg/tcg.c
Log Message:
-----------
tcg: Reset free_temps before tcg_optimize
When allocating new temps during tcg_optmize, do not re-use
any EBB temps that were used within the TB. We do not have
any idea what span of the TB in which the temp was live.
Introduce tcg_temp_ebb_reset_freed and use before tcg_optimize,
as well as replacing the equivalent in plugin_gen_inject and
tcg_func_start.
Cc: [email protected]
Fixes: fb04ab7ddd8 ("tcg/optimize: Lower TCG_COND_TST{EQ,NE} if unsupported")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2711
Reported-by: wannacu <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 04e006ab36a8565b92d4e21dd346367fbade7d74)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 242376e87245daf9e8811c8a161549c019f5933c
https://github.com/qemu/qemu/commit/242376e87245daf9e8811c8a161549c019f5933c
Author: Roman Artemev <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M tcg/riscv/tcg-target.c.inc
Log Message:
-----------
tcg/riscv: Fix StoreStore barrier generation
On RISC-V to StoreStore barrier corresponds
`fence w, w` not `fence r, r`
Cc: [email protected]
Fixes: efbea94c76b ("tcg/riscv: Add slowpath load and store instructions")
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Denis Tomashev <[email protected]>
Signed-off-by: Roman Artemev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b438362a142527b97b638b7f0f35ebe11911a8d5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 05e984c200a21a9f63d6c4f88b197d5d80b0a8fb
https://github.com/qemu/qemu/commit/05e984c200a21a9f63d6c4f88b197d5d80b0a8fb
Author: Gerd Hoffmann <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
M hw/i386/x86-common.c
Log Message:
-----------
x86/loader: only patch linux kernels
If the binary loaded via -kernel is *not* a linux kernel (in which
case protocol == 0), do not patch the linux kernel header fields.
It's (a) pointless and (b) might break binaries by random patching
and (c) changes the binary hash which in turn breaks secure boot
verification.
Background: OVMF happily loads and runs not only linux kernels but
any efi binary via direct kernel boot.
Note: Breaking the secure boot verification is a problem for linux
kernels too, but fixed that is left for another day ...
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 57e2cc9abf5da38f600354fe920ff20e719607b4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 83daae51ee6afbd2b0d79ae5e6924d6c7a840eb4
https://github.com/qemu/qemu/commit/83daae51ee6afbd2b0d79ae5e6924d6c7a840eb4
Author: Gerd Hoffmann <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
M roms/Makefile
Log Message:
-----------
roms: re-add edk2-basetools target
Needed to build ipxe nic roms.
Reported-by: Liu Jaloo <[email protected]>
Fixes: 22e11539e167 ("edk2: replace build scripts")
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 0f5715e4b5706b31b3550d8e6b88871e029c7823)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fa232044a5b21da5721dd89c1d60509f7c9b109a
https://github.com/qemu/qemu/commit/fa232044a5b21da5721dd89c1d60509f7c9b109a
Author: Heinrich Schuchardt <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
A pc-bios/descriptors/60-edk2-riscv64.json
M pc-bios/descriptors/meson.build
Log Message:
-----------
pc-bios: add missing riscv64 descriptor
Without descriptor libvirt cannot discover the EDK II binaries via
the qemu:///system connection.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
(cherry picked from commit 74dc38d0c6c15fd57a5dee94125d13ac5b00491d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ad06bb324d3a87582e8d5a6b1cd420714cf6c681
https://github.com/qemu/qemu/commit/ad06bb324d3a87582e8d5a6b1cd420714cf6c681
Author: Peter Maydell <[email protected]>
Date: 2024-12-19 (Thu, 19 Dec 2024)
Changed paths:
M hw/intc/arm_gicv3_its.c
Log Message:
-----------
hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs
In the GICv3 ITS model, we have a common coding pattern which has a
local C struct like "DTEntry dte", which is a C representation of an
in-guest-memory data structure, and we call a function such as
get_dte() to read guest memory and fill in the C struct. These
functions to read in the struct sometimes have cases where they will
leave early and not fill in the whole struct (for instance get_dte()
will set "dte->valid = false" and nothing else for the case where it
is passed an entry_addr implying that there is no L2 table entry for
the DTE). This then causes potential use of uninitialized memory
later, for instance when we call a trace event which prints all the
fields of the struct. Sufficiently advanced compilers may produce
-Wmaybe-uninitialized warnings about this, especially if LTO is
enabled.
Rather than trying to carefully separate out these trace events into
"only the 'valid' field is initialized" and "all fields can be
printed", zero-init all the structs when we define them. None of
these structs are large (the biggest is 24 bytes) and having
consistent behaviour is less likely to be buggy.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 9678b9c505725732353baefedb88b53c2eb8a184)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 42490ac98088a744113589aa75400d9db714776d
https://github.com/qemu/qemu/commit/42490ac98088a744113589aa75400d9db714776d
Author: Thomas Huth <[email protected]>
Date: 2024-12-20 (Fri, 20 Dec 2024)
Changed paths:
M meson.build
Log Message:
-----------
meson.build: Disallow libnfs v6 to fix the broken macOS build
The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).
Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2dc652961d6a9508d5db140765a0b22238165d88
https://github.com/qemu/qemu/commit/2dc652961d6a9508d5db140765a0b22238165d88
Author: Maciej S. Szmigiero <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
M accel/kvm/kvm-all.c
M configs/targets/i386-softmmu.mak
M configs/targets/x86_64-softmmu.mak
M include/sysemu/kvm.h
M target/i386/kvm/kvm.c
Log Message:
-----------
target/i386: Reset TSCs of parked vCPUs too on VM reset
Since commit 5286c3662294 ("target/i386: properly reset TSC on reset")
QEMU writes the special value of "1" to each online vCPU TSC on VM reset
to reset it.
However parked vCPUs don't get that handling and due to that their TSCs
get desynchronized when the VM gets reset.
This in turn causes KVM to turn off PVCLOCK_TSC_STABLE_BIT in its exported
PV clock.
Note that KVM has no understanding of vCPU being currently parked.
Without PVCLOCK_TSC_STABLE_BIT the sched clock is marked unstable in
the guest's kvm_sched_clock_init().
This causes a performance regressions to show in some tests.
Fix this issue by writing the special value of "1" also to TSCs of parked
vCPUs on VM reset.
Reproducing the issue:
1) Boot a VM with "-smp 2,maxcpus=3" or similar
2) device_add
host-x86_64-cpu,id=vcpu,node-id=0,socket-id=0,core-id=2,thread-id=0
3) Wait a few seconds
4) device_del vcpu
5) Inside the VM run:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is 1.
6) Reboot the VM
7) Once the VM boots once again run inside it:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is now 0.
Fixes: 5286c3662294 ("target/i386: properly reset TSC on reset")
Signed-off-by: Maciej S. Szmigiero <[email protected]>
Link:
https://lore.kernel.org/r/5a605a88e9a231386dc803c60f5fed9b48108139.1734014926.git.maciej.szmigi...@oracle.com
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3f2a05b31ee9ce2ddb6c75a9bc3f5e7f7af9a76f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19484ed99afb6f475000a4d54b9a7aa8c45778d7
https://github.com/qemu/qemu/commit/19484ed99afb6f475000a4d54b9a7aa8c45778d7
Author: Yong-Xuan Wang <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
M hw/intc/riscv_aplic.c
Log Message:
-----------
hw/intc/riscv_aplic: Fix APLIC in_clrip and clripnum write emulation
In the section "4.7 Precise effects on interrupt-pending bits"
of the RISC-V AIA specification defines that:
"If the source mode is Level1 or Level0 and the interrupt domain
is configured in MSI delivery mode (domaincfg.DM = 1):
The pending bit is cleared whenever the rectified input value is
low, when the interrupt is forwarded by MSI, or by a relevant
write to an in_clrip register or to clripnum."
Update the riscv_aplic_set_pending() to match the spec.
Fixes: bf31cf06eb ("hw/intc/riscv_aplic: Fix setipnum_le write emulation for
APLIC MSI-mode")
Signed-off-by: Yong-Xuan Wang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 0d0141fadc9063e527865ee420b2baf34e306093)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9d913e012b4328dab3c6b4e07907f3b87675fede
https://github.com/qemu/qemu/commit/9d913e012b4328dab3c6b4e07907f3b87675fede
Author: David Hildenbrand <[email protected]>
Date: 2024-12-24 (Tue, 24 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x/s390-virtio-ccw: don't crash on weird RAM sizes
KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
kvm_set_phys_mem: error registering slot: Invalid argument
Aborted (core dumped)
Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Acked-by: Janosch Frank <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 15eedfd2ff08e34fe19d86dd41d0ee646fa7774d
https://github.com/qemu/qemu/commit/15eedfd2ff08e34fe19d86dd41d0ee646fa7774d
Author: Bibo Mao <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M target/loongarch/tcg/insn_trans/trans_vec.c.inc
Log Message:
-----------
target/loongarch: Use actual operand size with vbsrl check
Hardcoded 32 bytes is used for vbsrl emulation check, there is
problem when options lsx=on,lasx=off is used for vbsrl.v instruction
in TCG mode. It injects LASX exception rather LSX exception.
Here actual operand size is used.
Cc: [email protected]
Fixes: df97f338076 ("target/loongarch: Implement xvreplve xvinsve0 xvpickve")
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit d41989e7548397b469ec9c7be4cee699321a317e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ad09b3df7e885428ba1d814dae7d2e3fcfac2c39
https://github.com/qemu/qemu/commit/ad09b3df7e885428ba1d814dae7d2e3fcfac2c39
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M docs/about/deprecated.rst
M docs/about/removed-features.rst
Log Message:
-----------
docs: Correct '-runas' and '-fsdev/-virtfs proxy' indentation
Use the same style for deprecated / removed commands.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 916f50172baa91ddf0e669a9d6d2747055c0e610)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 64092b346494bae2c366de15d32f83b4fae0594d
https://github.com/qemu/qemu/commit/64092b346494bae2c366de15d32f83b4fae0594d
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M docs/about/removed-features.rst
Log Message:
-----------
docs: Correct release of TCG trace-events removal
TCG trace-events were deprecated before the v6.2 release,
and removed for v7.0.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit b4859e8f33a7d9c793a60395f792c10190cb4f78)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9bbaadbf9cfb5ae60e3ecff00ef56283e21fbfb7
https://github.com/qemu/qemu/commit/9bbaadbf9cfb5ae60e3ecff00ef56283e21fbfb7
Author: Han Han <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386/cpu: Fix notes for CPU models
Fixes: 644e3c5d812 ("missing vmx features for Skylake-Server and
Cascadelake-Server")
Signed-off-by: Han Han <[email protected]>
Reviewed-by: Chenyi Qiang <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 93dcc9390e5ad0696ae7e9b7b3a5b08c2d1b6de6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f5827eb0ac3af024918fb702690188210c31202c
https://github.com/qemu/qemu/commit/f5827eb0ac3af024918fb702690188210c31202c
Author: Shameer Kolothum <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M migration/multifd-uadk.c
Log Message:
-----------
migration/multifd: Fix compile error caused by page_size usage
>From Commit 90fa121c6c07 ("migration/multifd: Inline page_size and
page_count") onwards page_size is not part of MutiFD*Params but uses
an inline constant instead.
However, it missed updating an old usage, causing a compile error.
Fixes: 90fa121c6c07 ("migration/multifd: Inline page_size and page_count")
Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit d127294f265e6a17f8d614f2bef7df8455e81f56)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7e4480dde246982f18b51d8f316a95a7dba2b825
https://github.com/qemu/qemu/commit/7e4480dde246982f18b51d8f316a95a7dba2b825
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M migration/multifd.c
Log Message:
-----------
migration/multifd: Fix compat with QEMU < 9.0
Commit f5f48a7891 ("migration/multifd: Separate SYNC request with
normal jobs") changed the multifd source side to stop sending data
along with the MULTIFD_FLAG_SYNC, effectively introducing the concept
of a SYNC-only packet. Relying on that, commit d7e58f412c
("migration/multifd: Don't send ram data during SYNC") later came
along and skipped reading data from SYNC packets.
In a versions timeline like this:
8.2 f5f48a7 9.0 9.1 d7e58f41 9.2
The issue arises that QEMUs < 9.0 still send data along with SYNC, but
QEMUs > 9.1 don't gather that data anymore. This leads to various
kinds of migration failures due to desync/missing data.
Stop checking for a SYNC packet on the destination and unconditionally
unfill the packet.
>From now on:
old -> new:
the source sends data + sync, destination reads normally
new -> new:
source sends only sync, destination reads zeros
new -> old:
source sends only sync, destination reads zeros
CC: [email protected]
Fixes: d7e58f412c ("migration/multifd: Don't send ram data during SYNC")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2720
Reviewed-by: Peter Xu <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit b93d897ea2f0abbe7fc341a9ac176b5ecd0f3c93)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ea3b821595fa474366743a293c19fa20ceb8506f
https://github.com/qemu/qemu/commit/ea3b821595fa474366743a293c19fa20ceb8506f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Add more error handling to analyze-migration.py
The analyze-migration script was seen failing in s390x in misterious
ways. It seems we're reaching the VMSDFieldStruct constructor without
any fields, which would indicate an empty .subsection entry, a
VMSTATE_STRUCT with no fields or a vmsd with no fields. We don't have
any of those, at least not without the unmigratable flag set, so this
should never happen.
Add some debug statements so that we can see what's going on the next
time the issue happens.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 86bee9e0c761a3d0e67c43b44001fd752f894cb0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: abb738ad333a8f5efe2cb7a76166a4375a782253
https://github.com/qemu/qemu/commit/abb738ad333a8f5efe2cb7a76166a4375a782253
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Remove unused argument in vmsd_desc_field_end
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2aead53d39b828f8d9d0769ffa3579dadd64d846)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e3839b0c19280be945a2af42b66483c09732bc5f
https://github.com/qemu/qemu/commit/e3839b0c19280be945a2af42b66483c09732bc5f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix parsing of s390 stream
The parsing for the S390StorageAttributes section is currently leaving
an unconsumed token that is later interpreted by the generic code as
QEMU_VM_EOF, cutting the parsing short.
The migration will issue a STATTR_FLAG_DONE between iterations, which
the script consumes correctly, but there's a final STATTR_FLAG_EOS at
.save_complete that the script is ignoring. Since the EOS flag is a
u64 0x1ULL and the stream is big endian, on little endian hosts a byte
read from it will be 0x0, the same as QEMU_VM_EOF.
Fixes: 81c2c9dd5d ("tests/qtest/migration-test: Fix analyze-migration.py for
s390x")
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 69d1f784569fdb950f2923c3b6d00d7c1b71acc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e7a9d9342865e5f7dcd836afa77990e1980b1986
https://github.com/qemu/qemu/commit/e7a9d9342865e5f7dcd836afa77990e1980b1986
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x: Fix CSS migration
Commit a55ae46683 ("s390: move css_migration_enabled from machine to
css.c") disabled CSS migration globally instead of doing it
per-instance.
CC: Paolo Bonzini <[email protected]>
CC: [email protected] #9.1
Fixes: a55ae46683 ("s390: move css_migration_enabled from machine to css.c")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2704
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit c76ee1f6255c3988a9447d363bb17072f1ec84e1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3ba6e1164a45f3345816921fec76d7bd12ed215a
https://github.com/qemu/qemu/commit/3ba6e1164a45f3345816921fec76d7bd12ed215a
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate-types.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Rename vmstate_info_nullptr
Rename vmstate_info_nullptr from "uint64_t" to "nullptr". This vmstate
actually reads and writes just a byte, so the proper name would be
uint8. However, since this is a marker for a NULL pointer, it's
convenient to have a more explicit name that can be identified by the
consumers of the JSON part of the stream.
Change the name to "nullptr" and add support for it in the
analyze-migration.py script. Arbitrarily use the name of the type as
the value of the field to avoid the script showing 0x30 or '0', which
could be confusing for readers.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit f52965bf0eeee28e89933264f1a9dbdcdaa76a7e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 46f2af3e3917b3aa8b65fdabcff79c2ce52b9e7f
https://github.com/qemu/qemu/commit/46f2af3e3917b3aa8b65fdabcff79c2ce52b9e7f
Author: Peter Xu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Dump correct JSON format for nullptr replacement
QEMU plays a trick with null pointers inside an array of pointers in a VMSD
field. See 07d4e69147 ("migration/vmstate: fix array of ptr with
nullptrs") for more details on why. The idea makes sense in general, but
it may overlooked the JSON writer where it could write nothing in a
"struct" in the JSON hints section.
We hit some analyze-migration.py issues on s390 recently, showing that some
of the struct field contains nothing, like:
{"name": "css", "array_len": 256, "type": "struct", "struct": {}, "size": 1}
As described in details by Fabiano:
https://lore.kernel.org/r/[email protected]
It could be that we hit some null pointers there, and JSON was gone when
they're null pointers.
To fix it, instead of hacking around only at VMStateInfo level, do that
from VMStateField level, so that JSON writer can also be involved. In this
case, JSON writer will replace the pointer array (which used to be a
"struct") to be the real representation of the nullptr field.
Signed-off-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 9867c3a7ced12dd7519155c047eb2c0098a11c5f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82565fb6b36cd37a37ff0b3380cbd58f76449957
https://github.com/qemu/qemu/commit/82565fb6b36cd37a37ff0b3380cbd58f76449957
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/vmstate.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix arrays of pointers in JSON writer
Currently, if an array of pointers contains a NULL pointer, that
pointer will be encoded as '0' in the stream. Since the JSON writer
doesn't define a "pointer" type, that '0' will now be an uint8, which
is different from the original type being pointed to, e.g. struct.
(we're further calling uint8 "nullptr", but that's irrelevant to the
issue)
That mixed-type array shouldn't be compressed, otherwise data is lost
as the code currently makes the whole array have the type of the first
element:
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 256, "type": "nullptr", "size": 1},
...,
]}
In the above, the valid pointer at position 254 got lost among the
compressed array of nullptr.
While we could disable the array compression when a NULL pointer is
found, the JSON part of the stream still makes part of downtime, so we
should avoid writing unecessary bytes to it.
Keep the array compression in place, but if NULL and non-NULL pointers
are mixed break the array into several type-contiguous pieces :
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 254, "type": "nullptr", "size": 1},
{"name": "css", "type": "struct", "struct": {"vmsd_name": "s390_css_img",
... }, "size": 768},
{"name": "css", "type": "nullptr", "size": 1},
...,
]}
Now each type-discontiguous region will become a new JSON entry. The
reader should interpret this as a concatenation of values, all part of
the same field.
Parsing the JSON with analyze-script.py now shows the proper data
being pointed to at the places where the pointer is valid and
"nullptr" where there's NULL:
"s390_css (14)": {
...
"css": [
"nullptr",
"nullptr",
...
"nullptr",
{
"chpids": [
{
"in_use": "0x00",
"type": "0x00",
"is_virtual": "0x00"
},
...
]
},
"nullptr",
}
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 35049eb0d2fc72bb8c563196ec75b4d6c13fce02)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7fb9ce40e75e06fe6d25c835830832e7c3940d03
https://github.com/qemu/qemu/commit/7fb9ce40e75e06fe6d25c835830832e7c3940d03
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-nocomp.c
Log Message:
-----------
multifd: bugfix for migration using compression methods
When compression is enabled on the migration channel and
the pages processed are all zero pages, these pages will
not be sent and updated on the target side, resulting in
incorrect memory data on the source and target sides.
The root cause is that all compression methods call
multifd_send_prepare_common to determine whether to compress
dirty pages, but multifd_send_prepare_common does not update
the IOV of MultiFDPacket_t when all dirty pages are zero pages.
The solution is to always update the IOV of MultiFDPacket_t
regardless of whether the dirty pages are all zero pages.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the
multifd thread.")
Cc: [email protected] #9.0+
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit cdc3970f8597ebdc1a4c2090cfb4d11e297329ed)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fcd5a157e6b21412bafb146027eb74057e053271
https://github.com/qemu/qemu/commit/fcd5a157e6b21412bafb146027eb74057e053271
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-qpl.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with QPL compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2588a5f99b0c3493b4690e3ff01ed36f80e830cc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9a17a650667bee2249310744b4508e9647b9a5bf
https://github.com/qemu/qemu/commit/9a17a650667bee2249310744b4508e9647b9a5bf
Author: Yuan Liu <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M migration/multifd-qatzip.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with qatzip compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit a523bc52166c80d8a04d46584f9f3868bd53ef69)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bb6940dbad20a90515fd53f901b370251e7a25df
https://github.com/qemu/qemu/commit/bb6940dbad20a90515fd53f901b370251e7a25df
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M tests/functional/test_rx_gdbsim.py
Log Message:
-----------
tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
Yoshinori said [*] URL references on OSDN were stable, but they
appear not to be. Mirror the artifacts on GitHub to avoid failures
while testing on CI.
[*] https://www.mail-archive.com/[email protected]/msg686487.html
Cc: Yoshinori Sato <[email protected]>
Reported-by: Alex Bennée <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[huth: Adapt the patch to the new version in the functional framework]
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit ec2dfb7c389b94d71ee825caa20b709d5df6c166)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: fixup for missing v9.2.0-421-g65d35a4e27a8 "tests/functional: convert
tests to new uncompress helper")
Commit: 48876bfc471ec02e5edcc935ba93e14426d891ab
https://github.com/qemu/qemu/commit/48876bfc471ec02e5edcc935ba93e14426d891ab
Author: Keoseong Park <[email protected]>
Date: 2025-01-15 (Wed, 15 Jan 2025)
Changed paths:
M hw/ufs/ufs.c
M tests/qtest/ufs-test.c
Log Message:
-----------
hw/ufs: Adjust value to match CPU's endian format
In ufs_write_attr_value(), the value parameter is handled in the CPU's
endian format but provided in big-endian format by the caller. Thus, it
is converted to the CPU's endian format. The related test code is also
fixed to reflect this change.
Fixes: 7c85332a2b3e ("hw/ufs: minor bug fixes related to ufs-test")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Keoseong Park <[email protected]>
Reviewed-by: Jeuk Kim <[email protected]>
Message-ID: <20250107084356epcms2p2af4d86432174d76ea57336933e46b4c3@epcms2p2>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 4572dacc33e232a7c951ba7ba7a20887fad29e71)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3b9b5cbe0ae0aa0e2fb166611d0d407df4a307e7
https://github.com/qemu/qemu/commit/3b9b5cbe0ae0aa0e2fb166611d0d407df4a307e7
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/qtest/boot-serial-test.c
Log Message:
-----------
tests/qtest/boot-serial-test: Correct HPPA machine name
Commit 7df6f751176 ("hw/hppa: Split out machine creation")
renamed the 'hppa' machine as 'B160L', but forgot to update
the boot serial test, which ended being skipped.
Cc: [email protected]
Fixes: 7df6f751176 ("hw/hppa: Split out machine creation")
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit a87077316ed2f1c1c8ba8faf05feed9dbf0f2fee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 69e29c484f68e0c754a5da6772ebd769de1c7fbf
https://github.com/qemu/qemu/commit/69e29c484f68e0c754a5da6772ebd769de1c7fbf
Author: Gabriel Barrantes <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M backends/cryptodev-vhost-user.c
Log Message:
-----------
backends/cryptodev-vhost-user: Fix local_error leaks
Do not propagate error to the upper, directly output the error
to avoid leaks.
Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714
Signed-off-by: Gabriel Barrantes <[email protected]>
Reviewed-by: zhenwei pi <[email protected]>
Message-Id:
<dm8pr13mb50781054a4fdace6f4fb6469b3...@dm8pr13mb5078.namprd13.prod.outlook.com>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 78b0c15a563ac4be5afb0375602ca0a3adc6c442)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4a3538e6f287b383daa82410769cec1b79e6df02
https://github.com/qemu/qemu/commit/4a3538e6f287b383daa82410769cec1b79e6df02
Author: Phil Dennis-Jordan <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/usb/hcd-xhci-pci.c
Log Message:
-----------
hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.
This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")
It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.
This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.
Signed-off-by: Phil Dennis-Jordan <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91b2cb9a78ae3b0487497e004c660016bc7b7b44
https://github.com/qemu/qemu/commit/91b2cb9a78ae3b0487497e004c660016bc7b7b44
Author: Sebastian Ott <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/pci/pcie.c
Log Message:
-----------
pci: ensure valid link status bits for downstream ports
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:
pcieport 0000:08:01.0: pciehp: Slot(2): Card present
pcieport 0000:08:01.0: pciehp: Slot(2): Link Up
pcieport 0000:08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000
There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0
Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.
Signed-off-by: Sebastian Ott <[email protected]>
Tested-by: Zhenyu Zhang <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c8fb662a5817ee3267430ffdc711c6ec7a4cb11e
https://github.com/qemu/qemu/commit/c8fb662a5817ee3267430ffdc711c6ec7a4cb11e
Author: Nicholas Piggin <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/pci/msix.c
Log Message:
-----------
pci/msix: Fix msix pba read vector poll end calculation
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.
Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Nicholas Piggin <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b107128ea6b3755e7ab5f9392ddffe8910caa9d0
https://github.com/qemu/qemu/commit/b107128ea6b3755e7ab5f9392ddffe8910caa9d0
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: whitelist expected blobs
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ad32644fe4c9fb25086be15a66dde1d55d3410f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7170aa66aaf794c972c31d126235716b28f00cdd
https://github.com/qemu/qemu/commit/7170aa66aaf794c972c31d126235716b28f00cdd
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
pci: acpi: Windows 'PCI Label Id' bug workaround
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.
Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fixed
in latest updates for 'Windows Server' but not in consumer
versions of Windows (and there is no plans to fix it
as far as I'm aware).
Given it's easy, implement Microsoft suggested workaround
(return invalid Package) so that affected Windows versions
could boot on QEMU.
This would effectvely remove bogus 'PCI Label Id's on NICs,
but MS teem confirmed that flipping 'PCI Label Id' should not
change 'Network Connection' ennumeration, so it should be safe
for QEMU to change _DSM without any compat code.
Smoke tested with WinXP and WS2022
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 0b053391985abcc40b16ac8fc4a7f6588d1d95c1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 73ca3ba37d6c20174bc649663c8fc359e6fecda9
https://github.com/qemu/qemu/commit/73ca3ba37d6c20174bc649663c8fc359e6fecda9
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/data/acpi/x86/pc/DSDT
M tests/data/acpi/x86/pc/DSDT.acpierst
M tests/data/acpi/x86/pc/DSDT.acpihmat
M tests/data/acpi/x86/pc/DSDT.bridge
M tests/data/acpi/x86/pc/DSDT.cphp
M tests/data/acpi/x86/pc/DSDT.dimmpxm
M tests/data/acpi/x86/pc/DSDT.hpbridge
M tests/data/acpi/x86/pc/DSDT.ipmikcs
M tests/data/acpi/x86/pc/DSDT.memhp
M tests/data/acpi/x86/pc/DSDT.nohpet
M tests/data/acpi/x86/pc/DSDT.numamem
M tests/data/acpi/x86/pc/DSDT.roothp
M tests/data/acpi/x86/q35/DSDT
M tests/data/acpi/x86/q35/DSDT.acpierst
M tests/data/acpi/x86/q35/DSDT.acpihmat
M tests/data/acpi/x86/q35/DSDT.acpihmat-generic-x
M tests/data/acpi/x86/q35/DSDT.acpihmat-noinitiator
M tests/data/acpi/x86/q35/DSDT.applesmc
M tests/data/acpi/x86/q35/DSDT.bridge
M tests/data/acpi/x86/q35/DSDT.core-count
M tests/data/acpi/x86/q35/DSDT.core-count2
M tests/data/acpi/x86/q35/DSDT.cphp
M tests/data/acpi/x86/q35/DSDT.cxl
M tests/data/acpi/x86/q35/DSDT.dimmpxm
M tests/data/acpi/x86/q35/DSDT.ipmibt
M tests/data/acpi/x86/q35/DSDT.ipmismbus
M tests/data/acpi/x86/q35/DSDT.ivrs
M tests/data/acpi/x86/q35/DSDT.memhp
M tests/data/acpi/x86/q35/DSDT.mmio64
M tests/data/acpi/x86/q35/DSDT.multi-bridge
M tests/data/acpi/x86/q35/DSDT.nohpet
M tests/data/acpi/x86/q35/DSDT.numamem
M tests/data/acpi/x86/q35/DSDT.pvpanic-isa
M tests/data/acpi/x86/q35/DSDT.thread-count
M tests/data/acpi/x86/q35/DSDT.thread-count2
M tests/data/acpi/x86/q35/DSDT.tis.tpm12
M tests/data/acpi/x86/q35/DSDT.tis.tpm2
M tests/data/acpi/x86/q35/DSDT.type4-count
M tests/data/acpi/x86/q35/DSDT.viot
M tests/data/acpi/x86/q35/DSDT.xapic
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: update expected blobs
_DSM function 7 AML should have followig change:
If ((Arg2 == 0x07))
{
- Local0 = Package (0x02)
- {
- Zero,
- ""
- }
Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One]
))
- Local0 [Zero] = Local2
+ Local0 = Package (0x02) {}
+ If (!((Local2 == Zero) || (Local2 == 0xFFFFFFFF)))
+ {
+ Local0 [Zero] = Local2
+ Local0 [One] = ""
+ }
+
Return (Local0)
}
}
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 9fb1c9a1bb26e111ee5fa5538070cd684de14c08)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: regenerate acpi tables for 9.2)
Commit: acc4e8b69b9d7a6fc30f0be63ce0bf4dffd5d560
https://github.com/qemu/qemu/commit/acc4e8b69b9d7a6fc30f0be63ce0bf4dffd5d560
Author: Li Zhijian <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M hw/mem/cxl_type3.c
Log Message:
-----------
hw/cxl: Fix msix_notify: Assertion `vector < dev->msix_entries_nr`
This assertion always happens when we sanitize the CXL memory device.
$ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
It is incorrect to register an MSIX number beyond the device's capability.
Increase the device's MSIX number to cover the mailbox msix number(9).
Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background
completion")
Signed-off-by: Li Zhijian <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ce979e7269a34d19ea1a65808df014d8b2acbf6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1032dccadb647cf517c9ee57ffd7acca2f88df5d
https://github.com/qemu/qemu/commit/1032dccadb647cf517c9ee57ffd7acca2f88df5d
Author: Paolo Bonzini <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M scripts/make-release
Log Message:
-----------
make-release: only leave tarball of wrap-file subprojects
The QEMU source archive is including the sources downloaded from crates.io
in both tarball form (in subprojects/packagecache) and expanded/patched
form (in the subprojects directory). The former is the more authoritative
form, as it has a hash that can be verified in the wrap file and checked
against the download URL, so keep that one only. This works also with
--disable-download; when building QEMU for the first time from the
tarball, Meson will print something like
Using proc-macro2-1-rs source from cache.
for each subproject, and then go on to extract the tarball and apply the
overlay or the patches in subprojects/packagefiles.
Reported-by: Michael Tokarev <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2719
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit be27b5149c86f81531f8fc609baf3480fc4d9ca0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2f5f6cb90ab3b854044db773e418ef9867d9c9ff
https://github.com/qemu/qemu/commit/2f5f6cb90ab3b854044db773e418ef9867d9c9ff
Author: Zhao Liu <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/cpu: Mark avx10_version filtered when prefix is NULL
In x86_cpu_filter_features(), if host doesn't support AVX10, the
configured avx10_version should be marked as filtered regardless of
whether prefix is NULL or not.
Check prefix before warn_report() instead of checking for
have_filtered_features.
Cc: [email protected]
Fixes: commit bccfb846fd52 ("target/i386: add AVX10 feature and AVX10 version
property")
Signed-off-by: Zhao Liu <[email protected]>
Reviewed-by: Tao Su <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit cf4c263551886964c5d58bd7b675b13fd497b402)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dcb80cd90832b11133f3c73706c63698f3b6e714
https://github.com/qemu/qemu/commit/dcb80cd90832b11133f3c73706c63698f3b6e714
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-01-22 (Wed, 22 Jan 2025)
Changed paths:
M crypto/pbkdf.c
Log Message:
-----------
crypto: fix bogus error benchmarking pbkdf on fast machines
We're seeing periodic reports of errors like:
$ qemu-img create -f luks --object secret,data=123456,id=sec0 \
-o key-secret=sec0 luks-info.img 1M
Formatting 'luks-info.img', fmt=luks size=1048576 key-secret=sec0
qemu-img: luks-info.img: Unable to get accurate CPU usage
This error message comes from a recent attempt to workaround a
kernel bug with measuring rusage in long running processes:
commit c72cab5ad9f849bbcfcf4be7952b8b8946cc626e
Author: Tiago Pasqualini <[email protected]>
Date: Wed Sep 4 20:52:30 2024 -0300
crypto: run qcrypto_pbkdf2_count_iters in a new thread
Unfortunately this has a subtle bug on machines which are very fast.
On the first time around the loop, the 'iterations' value is quite
small (1 << 15), and so will run quite fast. Testing has shown that
some machines can complete this benchmarking task in as little as
7 milliseconds.
Unfortunately the 'getrusage' data is not updated at the time of
the 'getrusage' call, it is done asynchronously by the scheduler.
The 7 millisecond completion time for the benchmark is short
enough that 'getrusage' sometimes reports 0 accumulated execution
time.
As a result the 'delay_ms == 0' sanity check in the above commit
is triggering non-deterministically on such machines.
The benchmarking loop intended to run multiple times, increasing
the 'iterations' value until the benchmark ran for > 500 ms, but
the sanity check doesn't allow this to happen.
To fix it, we keep a loop counter and only run the sanity check
after we've been around the loop more than 5 times. At that point
the 'iterations' value is high enough that even with infrequent
updates of 'getrusage' accounting data on fast machines, we should
see a non-zero value.
Fixes:
https://lore.kernel.org/qemu-devel/[email protected]/
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2336437
Reported-by: Thomas Huth <[email protected]>
Reported-by: Richard W.M. Jones <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 145f12ea885c8fcfbe2d0ac5230630f071b5a9fb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c597e6f26d41cf17e3ecfaa12dccb5c85949eaaf
https://github.com/qemu/qemu/commit/c597e6f26d41cf17e3ecfaa12dccb5c85949eaaf
Author: Zhao Liu <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M stubs/meson.build
Log Message:
-----------
stub: Fix build failure with --enable-user --disable-system --enable-tools
Configuring "--enable-user --disable-system --enable-tools" causes the
build failure with the following information:
/usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function `device_finalize':
/qemu/build/../hw/core/qdev.c:688: undefined reference to
`qapi_event_send_device_deleted'
collect2: error: ld returned 1 exit status
To fix the above issue, add qdev.c stub when build with `have_tools`.
With this fix, QEMU could be successfully built in the following cases:
--enable-user --disable-system --enable-tools
--enable-user --disable-system --disable-tools
--enable-user --disable-system
Cc: [email protected]
Fixes: 388b849fb6c3 ("stubs: avoid duplicate symbols in libqemuutil.a")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2766
Signed-off-by: Zhao Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 8113dbbcdaee05f319a7e48272416d918cb2b04a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c806bbe8c161d0524648fc6fe024ceefbb833071
https://github.com/qemu/qemu/commit/c806bbe8c161d0524648fc6fe024ceefbb833071
Author: Peter Maydell <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: arm_reset_sve_state() should set FPSR, not FPCR
The pseudocode ResetSVEState() does:
FPSR = ZeroExtend(0x0800009f<31:0>, 64);
but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident.
Before the advent of FEAT_AFP, this was only setting a collection of
RES0 bits, which vfp_set_fpsr() would then ignore, so the only effect
was that we didn't actually set the FPSR the way we are supposed to
do. Once FEAT_AFP is implemented, setting the bottom bits of FPSR
will change the floating point behaviour.
Call vfp_set_fpsr(), as we ought to.
(Note for stable backports: commit 7f2a01e7368f9 moved this function
from sme_helper.c to helper.c, but it had the same bug before the
move too.)
Cc: [email protected]
Fixes: f84734b87461 ("target/arm: Implement SMSTART, SMSTOP")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1edc3d43f20df0d04f8d00b906ba19fed37512a5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e82fbf01b61fef16fe0bd354198aeb42f920a4ba
https://github.com/qemu/qemu/commit/e82fbf01b61fef16fe0bd354198aeb42f920a4ba
Author: Hongren Zheng <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M hw/usb/canokey.c
M hw/usb/canokey.h
Log Message:
-----------
hw/usb/canokey: Fix buffer overflow for OUT packet
When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.
It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep_out as the target
buffer.
This is reported by a security researcher who artificially
constructed an OUT packet of size 2047. The report has gone
through the QEMU security process, and as this device is for
testing purpose and no deployment of it in virtualization
environment is observed, it is triaged not to be a security bug.
Cc: [email protected]
Fixes: d7d34918551dc48 ("hw/usb: Add CanoKey Implementation")
Reported-by: Juan Jose Lopez Jaimez <[email protected]>
Signed-off-by: Hongren Zheng <[email protected]>
Message-id: Z4TfMOrZz6IQYl_h@Sun
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 664280abddcb3cacc9c6204706bb739fcc1316f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7fd0224457aadf94176e4d94008db94cbdc8004a
https://github.com/qemu/qemu/commit/7fd0224457aadf94176e4d94008db94cbdc8004a
Author: Steve Sistare <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M system/physmem.c
Log Message:
-----------
physmem: fix qemu_ram_alloc_from_fd size calculation
qemu_ram_alloc_from_fd allocates space if file_size == 0. If non-zero,
it uses the existing space and verifies it is large enough, but the
verification was broken when the offset parameter was introduced. As
a result, a file smaller than offset passes the verification and causes
errors later. Fix that, and update the error message to include offset.
Peter provides this concise reproducer:
$ touch ramfile
$ truncate -s 64M ramfile
$ ./qemu-system-x86_64 -object
memory-backend-file,mem-path=./ramfile,offset=128M,size=128M,id=mem1,prealloc=on
qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad
address
With the fix, the error message is:
qemu-system-x86_64: mem1 backing store size 0x4000000 is too small for 'size'
option 0x8000000 plus 'offset' option 0x8000000
Cc: [email protected]
Fixes: 4b870dc4d0c0 ("hostmem-file: add offset option")
Signed-off-by: Steve Sistare <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 719168fba7c3215cc996dcfd32a6e5e9c7b8eee0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 066b9de4b3010c5071775d986487127772963664
https://github.com/qemu/qemu/commit/066b9de4b3010c5071775d986487127772963664
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M target/s390x/tcg/mem_helper.c
Log Message:
-----------
target/s390x: Fix MVC not always invalidating translation blocks
Node.js crashes in qemu-system-s390x with random SIGSEGVs / SIGILLs.
The v8 JIT used by Node.js can garbage collect and overwrite unused
code. Overwriting is performed by WritableJitAllocation::CopyCode(),
which ultimately calls memcpy(). For certain sizes, memcpy() uses the
MVC instruction.
QEMU implements MVC and other similar instructions using helpers. While
TCG store ops invalidate affected translation blocks automatically,
helpers must do this manually by calling probe_access_flags(). The MVC
helper does this using the access_prepare() -> access_prepare_nf() ->
s390_probe_access() -> probe_access_flags() call chain.
At the last step of this chain, the store size is replaced with 0. This
causes the probe_access_flags() -> notdirty_write() ->
tb_invalidate_phys_range_fast() chain to miss some translation blocks.
When this happens, QEMU executes a mix of old and new code. This
quickly leads to either a SIGSEGV or a SIGILL in case the old code
ends in the middle of a new instruction.
Fix by passing the true size.
Reported-by: Berthold Gunreben <[email protected]>
Cc: Sarah Kriesch <[email protected]>
Cc: [email protected]
Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1235709
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Fixes: e2faabee78ff ("accel/tcg: Forward probe size on to notdirty_write")
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e43ced8be18dda77c229ab09f85136a4d600d40d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: eec417351f6a2ff01aa077bda505783b2ae9dfc8
https://github.com/qemu/qemu/commit/eec417351f6a2ff01aa077bda505783b2ae9dfc8
Author: Laurent Vivier <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M net/net.c
Log Message:
-----------
net: Fix announce_self
b9ad513e1876 ("net: Remove receive_raw()") adds an iovec entry
in qemu_deliver_packet_iov() to add the virtio-net header
in the data when QEMU_NET_PACKET_FLAG_RAW is set but forgets
to increase the number of iovec entries in the array, so
receive_iov() will only send the first entry (the virtio-net
entry, full of 0) and no data. The packet will be discarded.
The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self.
We can see the problem with tcpdump:
- QEMU parameters:
.. -monitor stdio \
-netdev bridge,id=netdev0,br=virbr0 \
-device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
- HMP command:
(qemu) announce_self
- TCP dump:
$ sudo tcpdump -nxi virbr0
without the fix:
<nothing>
with the fix:
ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, length
46
0x0000: 0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
0x0010: 0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000 0000
Reported-by: Xiaohui Li <[email protected]>
Bug: https://issues.redhat.com/browse/RHEL-73891
Fixes: b9ad513e1876 ("net: Remove receive_raw()")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 84dfdcbff33fff185528501be408c25c44499f32)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7dc66ede715410ef9f0e0e09d54c28b36da4dd95
https://github.com/qemu/qemu/commit/7dc66ede715410ef9f0e0e09d54c28b36da4dd95
Author: Laurent Vivier <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M net/dump.c
Log Message:
-----------
net/dump: Correctly compute Ethernet packet offset
When a packet is sent with QEMU_NET_PACKET_FLAG_RAW by QEMU it
never includes virtio-net header even if qemu_get_vnet_hdr_len()
is not 0, and filter-dump is not managing this case.
The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self,
we can show the problem using it and tcpddump:
- QEMU parameters:
.. -monitor stdio \
-netdev bridge,id=netdev0,br=virbr0 \
-device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
-object filter-dump,netdev=netdev0,file=log.pcap,id=pcap0
- HMP command:
(qemu) announce_self
- TCP dump:
$ tcpdump -nxr log.pcap
without the fix:
08:00:06:04:00:03 > 2e:2f:80:35:00:01, ethertype Unknown (0x9a2b), length
50:
0x0000: 2c2d 2e2f 0000 0000 9a2b 2c2d 2e2f 0000
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000
0x0020: 0000 0000
with the fix:
ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f,
length 46
0x0000: 0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
0x0010: 0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000 0000
Fixes: 481c52320a26 ("net: Strip virtio-net header when dumping")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit c6a1b591a68b4d7230d6c3f56965e18080d737e5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4404720764db6e352cefe344be361308584d05d1
https://github.com/qemu/qemu/commit/4404720764db6e352cefe344be361308584d05d1
Author: Dominik 'Disconnect3d' Czarnota <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M gdbstub/user-target.c
Log Message:
-----------
gdbstub/user-target: fix gdbserver int format (%d -> %x)
This commit fixes an incorrect format string for formatting integers
provided to GDB when debugging a target run in QEMU user mode.
The correct format is hexadecimal for both success and errno values,
some of which can be seen here [0].
[0]
https://github.com/bminor/binutils-gdb/blob/e65a355022d0dc6b5707310876a72b5693ec0aa5/gdbserver/hostio.cc#L196-L213
Signed-off-by: Dominik 'Disconnect3d' Czarnota <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Fixes: e282010b2e1e ("gdbstub: Add support for info proc mappings")
Cc: [email protected]
Reviewed-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 8b647bd352505234cab2acd2422aba183a1aa1fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cac3fb4414778eab741a5e58ca0a30f1edc9528a
https://github.com/qemu/qemu/commit/cac3fb4414778eab741a5e58ca0a30f1edc9528a
Author: Michael Tokarev <[email protected]>
Date: 2025-02-08 (Sat, 08 Feb 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 9.2.1 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/ae35f033b874...cac3fb441477
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
