Branch: refs/heads/stable-10.1
Home: https://github.com/qemu/qemu
Commit: c3ae83117dfb198eae7f8afe8609e69674732cdb
https://github.com/qemu/qemu/commit/c3ae83117dfb198eae7f8afe8609e69674732cdb
Author: Damien Bergamini <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M docs/pcie_sriov.txt
M hw/net/igbvf.c
M hw/nvme/ctrl.c
M hw/pci/pci.c
M hw/pci/pcie_sriov.c
M include/hw/pci/pcie_sriov.h
Log Message:
-----------
pcie_sriov: Fix broken MMIO accesses from SR-IOV VFs
Starting with commit cab1398a60eb, SR-IOV VFs are realized as soon as
pcie_sriov_pf_init() is called. Because pcie_sriov_pf_init() must be
called before pcie_sriov_pf_init_vf_bar(), the VF BARs types won't be
known when the VF realize function calls pcie_sriov_vf_register_bar().
This breaks the memory regions of the VFs (for instance with igbvf):
$ lspci
...
Region 0: Memory at 281a00000 (64-bit, prefetchable) [virtual] [size=16K]
Region 3: Memory at 281a20000 (64-bit, prefetchable) [virtual] [size=16K]
$ info mtree
...
address-space: pci_bridge_pci_mem
0000000000000000-ffffffffffffffff (prio 0, i/o): pci_bridge_pci
0000000081a00000-0000000081a03fff (prio 1, i/o): igbvf-mmio
0000000081a20000-0000000081a23fff (prio 1, i/o): igbvf-msix
and causes MMIO accesses to fail:
Invalid write at addr 0x281A01520, size 4, region '(null)', reason: rejected
Invalid read at addr 0x281A00C40, size 4, region '(null)', reason: rejected
To fix this, VF BARs are now registered with pci_register_bar() which
has a type parameter and pcie_sriov_vf_register_bar() is removed.
Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances")
Signed-off-by: Damien Bergamini <[email protected]>
Signed-off-by: Clement Mathieu--Drif <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 2e54e5fda779a7ba45578884276dca62462f7a06)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 38702766185ae57dce440e811548fe92e19b39a1
https://github.com/qemu/qemu/commit/38702766185ae57dce440e811548fe92e19b39a1
Author: ShengYi Hung <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M hw/input/hid.c
Log Message:
-----------
hid: fix incorrect return value for hid
The return value of hid_keyboard_write is used to set the packet's actual_length
and pass to xhci directly to allow guest know how many byte actually processed.
Therefore, return 1 to indicate a successful transfer or it will be
considered as a wrong xfer.
Signed-off-by: ShengYi Hung <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 1c0f5142d921525f1023152eac63d2ff3d33e3b2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 30ff0b5651cfec991b6b32d426cb4ac5417f2646
https://github.com/qemu/qemu/commit/30ff0b5651cfec991b6b32d426cb4ac5417f2646
Author: nanliu <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M docs/devel/uefi-vars.rst
Log Message:
-----------
docs/devel: Correct uefi-vars-x64 device name
The documentation for UEFI variable storage in uefi-vars.rst
incorrectly listed the device name as `uefi-vars-x86`.
The correct device name as implemented in the source code is
`uefi-vars-x64`.
This commit updates the documentation to use the correct name,
aligning it with the implementation.
Signed-off-by: Nana Liu <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit f65918497cc6b9034ce8f81a4df1d6407e110367)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3a27ff6cb9f40cbc9fbe853e9ebcce7125408770
https://github.com/qemu/qemu/commit/3a27ff6cb9f40cbc9fbe853e9ebcce7125408770
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M hw/pci/pcie_sriov.c
Log Message:
-----------
pcie_sriov: make pcie_sriov_pf_exit() safe on non-SR-IOV devices
Commit 3f9cfaa92c96 ("virtio-pci: Implement SR-IOV PF") added an
unconditional call from virtio_pci_exit() to pcie_sriov_pf_exit().
pcie_sriov_pf_exit() reads from the SR-IOV Capability in Configuration
Space:
uint8_t *cfg = dev->config + dev->exp.sriov_cap;
...
unparent_vfs(dev, pci_get_word(cfg + PCI_SRIOV_TOTAL_VF));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This results in undefined behavior when dev->exp.sriov_cap is 0 because
this is not an SR-IOV device. For example, unparent_vfs() segfaults when
total_vfs happens to be non-zero.
Fix this by returning early from pcie_sriov_pf_exit() when
dev->exp.sriov_cap is 0 because this is not an SR-IOV device.
Cc: Akihiko Odaki <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Reported-by: Qing Wang <[email protected]>
Buglink: https://issues.redhat.com/browse/RHEL-116443
Signed-off-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances")
Reviewed-by: Michael S. Tsirkin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit bab681f752048c3bc22d561b1d314c7ec16419c9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19a3344754e10b42cef5a26b72773008e3e5bc02
https://github.com/qemu/qemu/commit/19a3344754e10b42cef5a26b72773008e3e5bc02
Author: Peter Maydell <[email protected]>
Date: 2025-10-08 (Wed, 08 Oct 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Don't set HCR.RW for AArch32 only CPUs
In commit 39ec3fc0301 we fixed a bug where we were not implementing
HCR_EL2.RW as RAO/WI for CPUs where EL1 doesn't support AArch32.
However, we got the condition wrong, so we now set this bit even on
CPUs which have no AArch64 support at all. This is wrong because the
AArch32 HCR register defines this bit as RES0.
Correct the condition we use for forcing HCR_RW to be set.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3128
Fixes: 39ec3fc0301 ("target/arm: HCR_EL2.RW should be RAO/WI if EL1 doesn't
support AArch32")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit a23e719ca8e80d22eafe4b2b57833918d439fa0c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1cea32f332f2f009d08307f84040c250c82f1111
https://github.com/qemu/qemu/commit/1cea32f332f2f009d08307f84040c250c82f1111
Author: Jim Shu <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
M target/riscv/insn_trans/trans_rvzicfiss.c.inc
Log Message:
-----------
target/riscv: Fix the mepc when sspopchk triggers the exception
When sspopchk is in the middle of TB and triggers the SW check
exception, it should update PC from gen_update_pc(). If not, RISC-V mepc
CSR will get wrong PC address which is still at the start of TB.
Signed-off-by: Jim Shu <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit c851052a77fd79300708df2070297b5428b4be8d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 45a31df407e7430e89312d7c012bd350021084f6
https://github.com/qemu/qemu/commit/45a31df407e7430e89312d7c012bd350021084f6
Author: Jim Shu <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
M target/riscv/csr.c
Log Message:
-----------
target/riscv: Fix SSP CSR error handling in VU/VS mode
In VU/VS mode, accessing $ssp CSR will trigger the virtual instruction
exception instead of illegal instruction exception if SSE is disabled
via xenvcfg CSRs.
This is from RISC-V CFI v1.0 spec ch2.2.4. Shadow Stack Pointer
Signed-off-by: Jim Shu <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 84c1605b7606d810ded4c1c3a2717f158dc89e3f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3a184ef664c1565cf34af5a8ec5dbb8b3b010a23
https://github.com/qemu/qemu/commit/3a184ef664c1565cf34af5a8ec5dbb8b3b010a23
Author: Jim Shu <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
M target/riscv/helper.h
M target/riscv/insn_trans/trans_rvzicfiss.c.inc
M target/riscv/op_helper.c
Log Message:
-----------
target/riscv: Fix ssamoswap error handling
Follow the RISC-V CFI v1.0 spec [1] to fix the exception type
when ssamoswap is disabled by xSSE.
[1] RISC-V CFI spec v1.0, ch2.7 Atomic Swap from a Shadow Stack Location
Signed-off-by: Jim Shu <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 0b16c7b6a854d461cdfd418769b51d58e43dd92a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: be9075c7c925459b69d52a27d552f823916f2512
https://github.com/qemu/qemu/commit/be9075c7c925459b69d52a27d552f823916f2512
Author: Max Chou <[email protected]>
Date: 2025-10-09 (Thu, 09 Oct 2025)
Changed paths:
M target/riscv/helper.h
M target/riscv/insn_trans/trans_rvv.c.inc
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: rvv: Fix vslide1[up|down].vx unexpected result when XLEN=32 and
SEW=64
When XLEN is 32 and SEW is 64, the original implementation of
vslide1up.vx and vslide1down.vx helper functions fills the 32-bit value
of rs1 into the first element of the destination vector register (rd),
which is a 64-bit element.
This commit attempted to resolve the issue by extending the rs1 value
to 64 bits during the TCG translation phase to ensure that the helper
functions won't lost the higer 32 bits.
Signed-off-by: Max Chou <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 81d1885dcc4424fec6761120f6e251eb3408fb8e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 608a19009a8d76e78333b9e20cc28f4f38762d83
https://github.com/qemu/qemu/commit/608a19009a8d76e78333b9e20cc28f4f38762d83
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-14 (Tue, 14 Oct 2025)
Changed paths:
M hw/i386/pc.c
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm/kvm.c
Log Message:
-----------
target/i386: add compatibility property for arch_capabilities
Prior to v10.1, if requested by user, arch-capabilities is always on
despite the fact that CPUID advertises it to be off/unvailable.
This causes a migration issue for VMs that are run on a machine
without arch-capabilities and expect this feature to be present
on the destination host with QEMU 10.1.
Add a compatibility property to restore the legacy behavior for all
machines with version prior to 10.1.
To preserve the functionality (added by 10.1) of turning off
ARCH_CAPABILITIES where Windows does not like it, use directly
the guest CPU vendor: x86_cpu_get_supported_feature_word is not
KVM-specific and therefore should not necessarily use the host
CPUID.
Co-authored-by: Hector Cao <[email protected]>
Signed-off-by: Hector Cao <[email protected]>
Fixes: d3a24134e37 ("target/i386: do not expose ARCH_CAPABILITIES on AMD CPU",
2025-07-17)
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit e9efa4a77168ac2816bf9471f878252ce6224710)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 400eeeefee2171684ffb177226d6e93826e5e597
https://github.com/qemu/qemu/commit/400eeeefee2171684ffb177226d6e93826e5e597
Author: Hector Cao <[email protected]>
Date: 2025-10-14 (Tue, 14 Oct 2025)
Changed paths:
M hw/i386/pc.c
M target/i386/cpu.c
M target/i386/cpu.h
Log Message:
-----------
target/i386: add compatibility property for pdcm feature
The pdcm feature is supposed to be disabled when PMU is not
available. Up until v10.1, pdcm feature is enabled even when PMU
is off. This behavior has been fixed but this change breaks the
migration of VMs that are run with QEMU < 10.0 and expect the pdcm
feature to be enabled on the destination host.
This commit restores the legacy behavior for machines with version
prior to 10.1 to allow the migration from older QEMU to QEMU 10.1.
Signed-off-by: Hector Cao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Fixes: e68ec298090 ("i386/cpu: Move adjustment of CPUID_EXT_PDCM before
feature_dependencies[] check", 2025-06-20)
[Move property from migration object to CPU. - Paolo]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 6529f31e0dccadb532c80b36e3efe7aef83f9cad)
Signed-off-by: Michael Tokarev <[email protected]>
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]>
Commit: ccaea6b2656ec6eab966585f7b16438208f98de7
https://github.com/qemu/qemu/commit/ccaea6b2656ec6eab966585f7b16438208f98de7
Author: Michael Tokarev <[email protected]>
Date: 2025-10-20 (Mon, 20 Oct 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 10.1.2 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/339768517a90...ccaea6b2656e
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
