Branch: refs/heads/staging-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]>
Compare: https://github.com/qemu/qemu/compare/339768517a90...400eeeefee21
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
