Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: f0839fec9415c8583ad1701a9b48f8a19fb507d6
https://github.com/qemu/qemu/commit/f0839fec9415c8583ad1701a9b48f8a19fb507d6
Author: Richard W.M. Jones <[email protected]>
Date: 2025-10-14 (Tue, 14 Oct 2025)
Changed paths:
M block/curl.c
M contrib/elf2dmp/download.c
Log Message:
-----------
block/curl.c: Use explicit long constants in curl_easy_setopt calls
curl_easy_setopt takes a variable argument that depends on what
CURLOPT you are setting. Some require a long constant. Passing a
plain int constant is potentially wrong on some platforms.
With warnings enabled, multiple warnings like this were printed:
../block/curl.c: In function ‘curl_init_state’:
../block/curl.c:474:13: warning: call to ‘_curl_easy_setopt_err_long’ declared
with attribute warning: curl_easy_setopt expects a long argument
[-Wattribute-warning]
474 | curl_easy_setopt(state->curl, CURLOPT_AUTOREFERER, 1) ||
| ^
Signed-off-by: Richard W.M. Jones <[email protected]>
Signed-off-by: Chenxi Mao <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit ed26056d90ddff21351f3efd2cb47fea4f0e1d45)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19ab9f31022e80acd45b796cd757885509ba5a35
https://github.com/qemu/qemu/commit/19ab9f31022e80acd45b796cd757885509ba5a35
Author: Mathias Krause <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/tcg/system/excp_helper.c
Log Message:
-----------
target/i386: Fix CR2 handling for non-canonical addresses
Commit 3563362ddfae ("target/i386: Introduce structures for mmu_translate")
accidentally modified CR2 for non-canonical address exceptions while these
should lead to a #GP / #SS instead -- without changing CR2.
Fix that.
A KUT test for this was submitted as [1].
[1] https://lore.kernel.org/kvm/[email protected]/
Fixes: 3563362ddfae ("target/i386: Introduce structures for mmu_translate")
Signed-off-by: Mathias Krause <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit df9a3372ddebfcfc135861fa2d53cef6f98065f9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9ca80ff5278a081f56e3fdbb058e70da3c160e42
https://github.com/qemu/qemu/commit/9ca80ff5278a081f56e3fdbb058e70da3c160e42
Author: Jon Kohler <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386/kvm: Expose ARCH_CAP_FB_CLEAR when invulnerable to MDS
Newer Intel hardware (Sapphire Rapids and higher) sets multiple MDS
immunity bits in MSR_IA32_ARCH_CAPABILITIES but lacks the hardware-level
MSR_ARCH_CAP_FB_CLEAR (bit 17):
ARCH_CAP_MDS_NO
ARCH_CAP_TAA_NO
ARCH_CAP_PSDP_NO
ARCH_CAP_FBSDP_NO
ARCH_CAP_SBDR_SSDP_NO
This prevents VMs with fb-clear=on from migrating from older hardware
(Cascade Lake, Ice Lake) to newer hardware, limiting live migration
capabilities. Note fb-clear was first introduced in v8.1.0 [1].
Expose MSR_ARCH_CAP_FB_CLEAR for MDS-invulnerable systems to enable
seamless migration between hardware generations.
Note: There is no impact when a guest migrates to newer hardware as
the existing bit combinations already mark the host as MMIO-immune and
disable FB_CLEAR operations in the kernel (see Linux's
arch_cap_mmio_immune() and vmx_update_fb_clear_dis()). See kernel side
discussion for [2] for additional context.
[1] 22e1094ca82 ("target/i386: add support for FB_CLEAR feature")
[2]
https://patchwork.kernel.org/project/kvm/patch/[email protected]/
Cc: Pawan Gupta <[email protected]>
Suggested-by: Sean Christopherson <[email protected]>
Signed-off-by: Jon Kohler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 00001a22d183ce96c110690987bf9dd6a8548552)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cf8dff8d9f92d75bbe16c391464b955fbb0d5720
https://github.com/qemu/qemu/commit/cf8dff8d9f92d75bbe16c391464b955fbb0d5720
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M hw/intc/apic.c
M target/i386/helper.c
M target/i386/tcg/system/seg_helper.c
Log Message:
-----------
i386/cpu: Prevent delivering SIPI during SMM in TCG mode
[commit message by YiFei Zhu]
A malicious kernel may control the instruction pointer in SMM in a
multi-processor VM by sending a sequence of IPIs via APIC:
CPU0 CPU1
IPI(CPU1, MODE_INIT)
x86_cpu_exec_reset()
apic_init_reset()
s->wait_for_sipi = true
IPI(CPU1, MODE_SMI)
do_smm_enter()
env->hflags |= HF_SMM_MASK;
IPI(CPU1, MODE_STARTUP, vector)
do_cpu_sipi()
apic_sipi()
/* s->wait_for_sipi check passes */
cpu_x86_load_seg_cache_sipi(vector)
A different sequence, SMI INIT SIPI, is also buggy in TCG because
INIT is not blocked or latched during SMM. However, it is not
vulnerable to an instruction pointer control in the same way because
x86_cpu_exec_reset clears env->hflags, exiting SMM.
Fixes: a9bad65d2c1f ("target-i386: wake up processors that receive an SMI")
Analyzed-by: YiFei Zhu <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit df32e5c568c9cf68c15a9bbd98d0c3aff19eab63)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 68630e670131b7a8694c0c3183cd757ab76341d9
https://github.com/qemu/qemu/commit/68630e670131b7a8694c0c3183cd757ab76341d9
Author: YiFei Zhu <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/tcg/system/smm_helper.c
Log Message:
-----------
i386/tcg/smm_helper: Properly apply DR values on SMM entry / exit
do_smm_enter and helper_rsm sets the env->dr, but does not sync the
values with cpu_x86_update_dr7. A malicious kernel may control the
instruction pointer in SMM by setting a breakpoint on the SMI
entry point, and after do_smm_enter cpu->breakpoints contains the
stale breakpoint; and because IDT is not reloaded upon SMI entry,
the debug exception handler controlled by the malicious kernel
is invoked.
Fixes: 01df040b5247 ("x86: Debug register emulation (Jan Kiszka)")
Reported-by: [email protected]
Signed-off-by: YiFei Zhu <[email protected]>
Link:
https://lore.kernel.org/r/2bacb9b24e9d337dbe48791aa25d349eb9c52c3a.1758794468.git.zhuyi...@google.com
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit cdba90ac1b0ac789b10c0b5f6ef7e9558237ec66)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b70ff85fef1a0d5102d930fd51e5d67254ff6ea4
https://github.com/qemu/qemu/commit/b70ff85fef1a0d5102d930fd51e5d67254ff6ea4
Author: Thomas Ogrisegg <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386: fix x86_64 pushw op
For x86_64 a 16 bit push op (pushw) of a memory address would generate
a 64 bit store on the stack instead of a 16 bit store.
For example:
pushw (%rax)
behaves like
pushq (%rax)
which is incorrect.
This patch fixes that.
Signed-off-by: Thomas Ogrisegg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5a2faa0a0a2cbdad4a108a0e122b0e51b9bc94fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f316e90a827b82a33d7f125e100dd05c5a4caf96
https://github.com/qemu/qemu/commit/f316e90a827b82a33d7f125e100dd05c5a4caf96
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/tcg/seg_helper.c
Log Message:
-----------
target/i386: fix access to the T bit of the TSS
The T bit is bit 0 of the 16-bit word at offset 100 of the TSS. However,
accessing it with a 32-bit word is not really correct, because bytes
102-103 contain the I/O map base address (relative to the base of the
TSS) and bits 1-15 are reserved. In particular, any task switch to a TSS that
has a nonzero I/O map base address is broken.
This fixes the eventinj and taskswitch tests in kvm-unit-tests.
Cc: [email protected]
Fixes: ad441b8b791 ("target/i386: implement TSS trap bit", 2025-05-12)
Reported-by: Thomas Huth <[email protected]>
Closes: https://gitlab.com/qemu-project/qemu/-/issues/3101
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0d22b621b7969eefde3535a0805977a334936fd7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4e58c5bf0cf7d0bb7bc6f7b277f490d3af9367c4
https://github.com/qemu/qemu/commit/4e58c5bf0cf7d0bb7bc6f7b277f490d3af9367c4
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M util/async.c
Log Message:
-----------
async: access bottom half flags with qatomic_read
Running test-aio-multithread under TSAN reveals data races on bh->flags.
Because bottom halves may be scheduled or canceled asynchronously,
without taking a lock, adjust aio_compute_bh_timeout() and aio_ctx_check()
to use a relaxed read to access the flags.
Use an acquire load to ensure that anything that was written prior to
qemu_bh_schedule() is visible.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2749
Closes: https://gitlab.com/qemu-project/qemu/-/issues/851
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5142397c79330aab9bef3230991c8ac0c251110f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 95c1555cd8c92a97db1f1fe352abcf55f0169830
https://github.com/qemu/qemu/commit/95c1555cd8c92a97db1f1fe352abcf55f0169830
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: user: do not set up a valid LDT on reset
In user-mode emulation, QEMU uses the default setting of the LDT base
and limit, which places it at the bottom 64K of virtual address space.
However, by default there is no LDT at all in Linux processes, and
therefore the limit should be 0.
This is visible as a NULL pointer dereference in LSL and LAR instructions
when they try to read the LDT at an unmapped address.
Resolves: #1376
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 58aa1d08bbc406ba3982f32ffb1bef0ff4f8f369)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e14614fe78bca37e8bdfa472ccf9b8aa49ec6e9e
https://github.com/qemu/qemu/commit/e14614fe78bca37e8bdfa472ccf9b8aa49ec6e9e
Author: Richard Henderson <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M accel/tcg/cputlb.c
Log Message:
-----------
accel/tcg: Hoist first page lookup above pointer_wrap
For strict alignment targets we registered cpu_pointer_wrap_notreached,
but generic code used it before recognizing the alignment exception.
Hoist the first page lookup, so that the alignment exception happens first.
Cc: [email protected]
Buglink: https://bugs.debian.org/1112285
Fixes: a4027ed7d4be ("target: Use cpu_pointer_wrap_notreached for strict align
targets")
Signed-off-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit ec03dd9723781c7e9d4b4f70c7f54d12da9459d5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e80709183ce5522eef0d0d1b5c1bfb437d6401de
https://github.com/qemu/qemu/commit/e80709183ce5522eef0d0d1b5c1bfb437d6401de
Author: Gabriel Brookman <[email protected]>
Date: 2025-10-17 (Fri, 17 Oct 2025)
Changed paths:
M target/hppa/insns.decode
Log Message:
-----------
target/hppa: correct size bit parity for fmpyadd
For the fmpyadd instruction on the hppa architecture, there is a bit
used to specify whether the instruction is operating on a 32 bit or
64 bit floating point register. For most instructions, such a bit is 0
when operating on the smaller register and 1 when operating on the
larger register. However, according to page 6-57 of the PA-RISC 1.1
Architecture and Instruction Set Reference Manual, this convention is
reversed for the fmpyadd instruction specifically, meaning the bit is
1 for operations on 32 bit registers and 0 for 64 bit registers. See
also page 6-18 (fig. 6-8) and 6-19 (table 6-16), where the f field
for FMPYADD and FMPYSUB is documented. Previously, QEMU decoded this
operation as operating on the other size of register, leading to bugs
when translating the fmpyadd instruction. This patch fixes that issue.
Reported-by: Andreas Hüttel <[email protected]>
Signed-off-by: Gabriel Brookman <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3096
Reviewed-by: Richard Henderson <[email protected]>
Acked-by: Helge Deller <[email protected]>
Message-ID:
<20251009-hppa-correct-fmpyadd-size-bit-decoding-v1-1-f63bb6c32...@gmail.com>
[PMD: Add documentation refs mentioned by Andreas K. Huettel]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit cea82f8cdd07697a48ae1c4e026707463f432a45)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: acef0da910ca9ce3e15b5dd92306f200e38a41c1
https://github.com/qemu/qemu/commit/acef0da910ca9ce3e15b5dd92306f200e38a41c1
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-10-17 (Fri, 17 Oct 2025)
Changed paths:
M linux-user/microblaze/target_elf.h
Log Message:
-----------
linux-user/microblaze: Fix little-endianness binary
MicroBlaze CPU model has a "little-endian" property, pointing to
the @endi internal field. Commit c36ec3a9655 ("hw/microblaze:
Explicit CPU endianness") took care of having all MicroBlaze
boards with an explicit default endianness, so later commit
415aae543ed ("target/microblaze: Consider endianness while
translating code") could infer the endianness at runtime from
the @endi field, and not a compile time via the TARGET_BIG_ENDIAN
definition. Doing so, we forgot to make the endianness explicit
on user emulation, so there all CPUs are started with the default
"little-endian=off" value, leading to breaking support for little
endian binaries:
$ readelf -h ./hello-world-mbel
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
$ qemu-microblazeel ./hello-world-mbel
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Fix by restoring the previous behavior of starting with the
builtin endianness of the binary:
$ qemu-microblazeel ./hello-world-mbel
Hello World
Cc: [email protected]
Fixes: 415aae543ed ("target/microblaze: Consider endianness while translating
code")
Reported-by: Edgar E. Iglesias <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 91fc6d8101de97c588e0a4263cf4f6148b3e702a)
(Mjt: adapt for missing v10.1.0-38-gaf880af8d4
"linux-user: Move get_elf_cpu_model to target/elfload.c")
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/400eeeefee21...acef0da910ca
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
