Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: deb02cd055a45e084cb821c2cea93e1988e4d899
https://github.com/qemu/qemu/commit/deb02cd055a45e084cb821c2cea93e1988e4d899
Author: Michael Tokarev <[email protected]>
Date: 2025-10-08 (Wed, 08 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]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21a79242f5cc6285b9c7f595f69c287f1cdfd626
https://github.com/qemu/qemu/commit/21a79242f5cc6285b9c7f595f69c287f1cdfd626
Author: Michael Tokarev <[email protected]>
Date: 2025-10-08 (Wed, 08 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 shuld not have been picked up for 10.0.x.
Reviewed-by: Zhao Liu <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c48db419833288b6da8d02bc00d4a83826a4cd95
https://github.com/qemu/qemu/commit/c48db419833288b6da8d02bc00d4a83826a4cd95
Author: Weifeng Liu <[email protected]>
Date: 2025-10-08 (Wed, 08 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: 36f45b6ba8808381a7899e86c20c56e0fab936ef
https://github.com/qemu/qemu/commit/36f45b6ba8808381a7899e86c20c56e0fab936ef
Author: Filip Hejsek <[email protected]>
Date: 2025-10-08 (Wed, 08 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: ae4e6ad050f91e67d532afabb9a4d175920a273d
https://github.com/qemu/qemu/commit/ae4e6ad050f91e67d532afabb9a4d175920a273d
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: cd18f194cc67d58381d31249a163214512042e87
https://github.com/qemu/qemu/commit/cd18f194cc67d58381d31249a163214512042e87
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: c5d7b508c03759def117be0754ba4249f5451ea6
https://github.com/qemu/qemu/commit/c5d7b508c03759def117be0754ba4249f5451ea6
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)
(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: e66dd9b390067d71a998e233c6a65be7b2bc7f4f
https://github.com/qemu/qemu/commit/e66dd9b390067d71a998e233c6a65be7b2bc7f4f
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: 6499d34a7f6436128eab29f08d8e0be73d2d112b
https://github.com/qemu/qemu/commit/6499d34a7f6436128eab29f08d8e0be73d2d112b
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: 9a0448a5fdb92b285ff695776535c8b8dfe3cafd
https://github.com/qemu/qemu/commit/9a0448a5fdb92b285ff695776535c8b8dfe3cafd
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: db89ee9f61a596c5ecf79e61800373800d4b8aae
https://github.com/qemu/qemu/commit/db89ee9f61a596c5ecf79e61800373800d4b8aae
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: 44c1ead4763905064892922194a4a78e43353c57
https://github.com/qemu/qemu/commit/44c1ead4763905064892922194a4a78e43353c57
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: c4a114c2ec86434ffcde4a6ff6635e9acd54d274
https://github.com/qemu/qemu/commit/c4a114c2ec86434ffcde4a6ff6635e9acd54d274
Author: Damien Bergamini <[email protected]>
Date: 2025-10-10 (Fri, 10 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: 16fc5fbd864ee6baa0614a87fdeee91c40c9ea3b
https://github.com/qemu/qemu/commit/16fc5fbd864ee6baa0614a87fdeee91c40c9ea3b
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]>
Compare: https://github.com/qemu/qemu/compare/918d584db4e8...16fc5fbd864e
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
