Branch: refs/heads/stable-10.0
Home: https://github.com/qemu/qemu
Commit: c5c0b16cf75ba9fcb8cec059ae0e1e5cf19a4a66
https://github.com/qemu/qemu/commit/c5c0b16cf75ba9fcb8cec059ae0e1e5cf19a4a66
Author: Michael Tokarev <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
Revert "target/i386: do not expose ARCH_CAPABILITIES on AMD CPU"
This reverts commit 24778b1c7ee7aca9721ed4757b0e0df0c16390f7
(v10.0.2-66-g24778b1c7ee7) from the 10.0.x branch.
The problem is that the change makes qemu 10.0.x non-migratable
to subsequent qemu versions, since it requires introducing a new
machine type.
This revert re-introduces the problem with windows guests (which
is already fixed in windows but not in prior versions).
Details: https://gitlab.com/qemu-project/qemu/-/issues/3001
Reviewed-by: Zhao Liu <[email protected]>
Reopens: https://gitlab.com/qemu-project/qemu/-/issues/3001 (for 10.0.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7917dee17a4cc82102a21f148d0ae845b446774f
https://github.com/qemu/qemu/commit/7917dee17a4cc82102a21f148d0ae845b446774f
Author: Michael Tokarev <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
Revert "i386/cpu: Move adjustment of CPUID_EXT_PDCM before
feature_dependencies[] check"
This reverts commit 3d26cb65c27190e57637644ecf6c96b8c3d246a3
(v10.0.3-34-g3d26cb65c271) from 10.0.x branch.
The problem is that the change makes qemu 10.0.x non-migratable
to subsequent qemu versions, since it requires introducing a new
machine type. This change should not have been picked up for 10.0.x.
Reviewed-by: Zhao Liu <[email protected]>
Reopens: https://gitlab.com/qemu-project/qemu/-/issues/3061 (for 10.0.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c784ce670300eac50d453d17ecce3c6ea697794e
https://github.com/qemu/qemu/commit/c784ce670300eac50d453d17ecce3c6ea697794e
Author: Weifeng Liu <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M ui/gtk.c
Log Message:
-----------
ui/gtk: Consider scaling when propagating ui info
The ui width and height sent to guest is supposed to be in buffer
coordinate. Hence conversion is required.
If scaling (global window scale and zooming scale) is not respected in
non-free-scale mode, window size could keep changing because of the
existence of the iteration of the following steps:
1. In resize event or configure event, a size larger (or smaller) than
the currently used one might be calculated due to not considering
scaling.
2. On reception of the display size change event in guest, the guest
might decide to do a mode setting and use the larger (or smaller)
mode.
3. When the new guest scan-out command arrives, QEMU would request the
window size to change to fit the new buffer size. This will trigger a
resize event or a configure event, making us go back to step 1.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit a1b28f71f7ff0fcafbe0672b788e8e57ee4fe8f6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8ec0e0b5025ec68f4aa55dbd8e538dd0ba12ae9b
https://github.com/qemu/qemu/commit/8ec0e0b5025ec68f4aa55dbd8e538dd0ba12ae9b
Author: Filip Hejsek <[email protected]>
Date: 2025-10-15 (Wed, 15 Oct 2025)
Changed paths:
M ui/gtk.c
Log Message:
-----------
ui/gtk: Fix callback function signature
The correct type for opaque pointer is gpointer,
not gpointer * (which is a pointer to a pointer).
Signed-off-by: Filip Hejsek <[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 c187a67c9dcdece58138f4df5ca4dd846934eddc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 45cd6b147b073a1433a416c5c1b4e2015ca941ad
https://github.com/qemu/qemu/commit/45cd6b147b073a1433a416c5c1b4e2015ca941ad
Author: ShengYi Hung <[email protected]>
Date: 2025-10-15 (Wed, 15 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: 63180b62bfafda556660f7395d6ef3a6472eac37
https://github.com/qemu/qemu/commit/63180b62bfafda556660f7395d6ef3a6472eac37
Author: nanliu <[email protected]>
Date: 2025-10-15 (Wed, 15 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: 7402c4dfe6c0614d0fd5528cda6c0666ab3d0b11
https://github.com/qemu/qemu/commit/7402c4dfe6c0614d0fd5528cda6c0666ab3d0b11
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-10-15 (Wed, 15 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)
(Mjt: backport to before v10.0.0-819-g19e55471d4e8
"pcie_sriov: Allow user to create SR-IOV device")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a81e4657adbed0724a36406a0f11c74670434434
https://github.com/qemu/qemu/commit/a81e4657adbed0724a36406a0f11c74670434434
Author: Peter Maydell <[email protected]>
Date: 2025-10-15 (Wed, 15 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: f64329b0ccb36c123aab074172ab579c0db3f939
https://github.com/qemu/qemu/commit/f64329b0ccb36c123aab074172ab579c0db3f939
Author: Jim Shu <[email protected]>
Date: 2025-10-15 (Wed, 15 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: e277608eae39024d1a260d3a64e5dd6b4bfaa983
https://github.com/qemu/qemu/commit/e277608eae39024d1a260d3a64e5dd6b4bfaa983
Author: Jim Shu <[email protected]>
Date: 2025-10-15 (Wed, 15 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: 0c21b32947b2ffa2f1027a6edea5e9f47284248e
https://github.com/qemu/qemu/commit/0c21b32947b2ffa2f1027a6edea5e9f47284248e
Author: Jim Shu <[email protected]>
Date: 2025-10-15 (Wed, 15 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: 381a32c3e20d89120c6167e3adb3b3c33d08c6b3
https://github.com/qemu/qemu/commit/381a32c3e20d89120c6167e3adb3b3c33d08c6b3
Author: Max Chou <[email protected]>
Date: 2025-10-15 (Wed, 15 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: 47f00fd978c671e232d77404c2c4bc7c5a514c60
https://github.com/qemu/qemu/commit/47f00fd978c671e232d77404c2c4bc7c5a514c60
Author: Damien Bergamini <[email protected]>
Date: 2025-10-15 (Wed, 15 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)
(This is a back-port of commit 2e54e5fda779 to 10.0.x)
Signed-off-by: Akihiko Odaki <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a0f78ee586ba94f504f5ad6dcc12fa09f7255f6b
https://github.com/qemu/qemu/commit/a0f78ee586ba94f504f5ad6dcc12fa09f7255f6b
Author: Richard W.M. Jones <[email protected]>
Date: 2025-10-15 (Wed, 15 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: ec60491c801621c7e0974924b749d359443abc13
https://github.com/qemu/qemu/commit/ec60491c801621c7e0974924b749d359443abc13
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: c1ff7b6ebaba8460a326c7b188947e52a3e08488
https://github.com/qemu/qemu/commit/c1ff7b6ebaba8460a326c7b188947e52a3e08488
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: 1e8a7c403a7349316116e5af77f508012e7fab24
https://github.com/qemu/qemu/commit/1e8a7c403a7349316116e5af77f508012e7fab24
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: c3f08ed6d0482556d1161faea7308462dc8ce055
https://github.com/qemu/qemu/commit/c3f08ed6d0482556d1161faea7308462dc8ce055
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: df1d0ce23b6a7e247409831fe6ec6b6c44ec0ceb
https://github.com/qemu/qemu/commit/df1d0ce23b6a7e247409831fe6ec6b6c44ec0ceb
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: bbdedf42f2a8ed71ce3f67f620166ba9b97e6225
https://github.com/qemu/qemu/commit/bbdedf42f2a8ed71ce3f67f620166ba9b97e6225
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: e2a2cdb07d9e94b14bd2be2a05ac5c5639b1b6b3
https://github.com/qemu/qemu/commit/e2a2cdb07d9e94b14bd2be2a05ac5c5639b1b6b3
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: 2d33b0091b8bf56ab94fe82adbd56eb6ce6049ee
https://github.com/qemu/qemu/commit/2d33b0091b8bf56ab94fe82adbd56eb6ce6049ee
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: 536f5ac0d761327cccc9d16bbe926a7d3398aac0
https://github.com/qemu/qemu/commit/536f5ac0d761327cccc9d16bbe926a7d3398aac0
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: e098f79eb26b5c4e4c04cc33321d188dcb20719f
https://github.com/qemu/qemu/commit/e098f79eb26b5c4e4c04cc33321d188dcb20719f
Author: Michael Tokarev <[email protected]>
Date: 2025-10-20 (Mon, 20 Oct 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 10.0.6 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/918d584db4e8...e098f79eb26b
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
