pcie_sriov: Fix configuration and state synchronization
Fix issues in PCIe SR-IOV configuration register handling that caused
inconsistent internal state due to improper write mask handling and
incorrect migration behavior.
Two main problems were identified:
1. VF Enable bit write mask handling:
pcie_sriov_config_write() incorrectly assumed that its val parameter
was already masked, causing it to ignore the actual write mask.
This led to the VF Enable bit being processed even when masked,
resulting in incorrect VF registration/unregistration. It is
identified as CVE-2025-54567.
2. Migration state inconsistency:
pcie_sriov_pf_post_load() unconditionally called register_vfs()
regardless of the VF Enable bit state, creating inconsistent
internal state when VFs should not be enabled. Additionally,
it failed to properly update the NumVFs write mask based on
the current configuration. It is identified as CVE-2025-54566.
Root cause analysis revealed that both functions relied on incorrect
special-case assumptions instead of properly reading and consuming
the actual configuration values. This change introduces a unified
consume_config() function that reads actual configuration values and
synchronize the internal state without special-case assumptions.
The solution only adds register read overhead in non-hot-path code
while ensuring correct SR-IOV state management across configuration
writes and migration scenarios.
Fixes: 5e7dd17e4348 ("pcie_sriov: Remove num_vfs from PCIESriovPF") Fixes: f9efcd47110d ("pcie_sriov: Register VFs after migration") Fixes: CVE-2025-54566 Fixes: CVE-2025-54567 Cc: qemu-stable@nongnu.org Reported-by: Corentin BAYET <corentin.bayet@reversetactics.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-Id: <20250727-wmask-v2-1-394910b1c0b6@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cad9aa6fbdccd95e56e10cfa57c354a20a333717)
(Mjt: context fix) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The expected initial state of the table depends on feature negotiation:
With VIRTIO_NET_F_CTRL_VLAN:
The table must be empty in accordance with the specification.
Without VIRTIO_NET_F_CTRL_VLAN:
The table must be filled to permit all VLAN traffic.
Prior to commit 06b636a1e2ad ("virtio-net: do not reset vlan filtering
at set_features"), virtio_net_set_features() always reset the VLAN
table. That commit changed the behavior to skip table reset when
VIRTIO_NET_F_CTRL_VLAN was negotiated, assuming the table would be
properly cleared during device reset and remain stable.
However, this assumption breaks when a driver renegotiates features:
1. Initial negotiation without VIRTIO_NET_F_CTRL_VLAN (table filled)
2. Renegotiation with VIRTIO_NET_F_CTRL_VLAN (table will not be cleared)
The problem was exacerbated by commit 0caed25cd171 ("virtio: Call
set_features during reset"), which triggered virtio_net_set_features()
during device reset, exposing the bug whenever VIRTIO_NET_F_CTRL_VLAN
was negotiated after a device reset.
Solution
--------
Fix the issue by initializing the table when virtio_net_set_features()
is called to change the VIRTIO_NET_F_CTRL_VLAN bit of
vdev->guest_features.
This approach ensures the correct table state regardless of feature
negotiation sequence by performing initialization in
virtio_net_set_features() as QEMU did prior to commit 06b636a1e2ad
("virtio-net: do not reset vlan filtering at set_features").
This change still preserves the goal of the commit, which was to avoid
resetting the table during migration, by checking whether the
VIRTIO_NET_F_CTRL_VLAN bit of vdev->guest_features is being changed;
vdev->guest_features is set before virtio_net_set_features() gets called
during migration.
It also avoids resetting the table when the driver sets a feature
bitmask with no change for the VIRTIO_NET_F_CTRL_VLAN bit, which makes
the operation idempotent and its semantics cleaner.
Additionally, this change ensures the table is initialized after
feature negotiation and before the DRIVER_OK status bit being set for
compatibility with the Linux driver before commit 50c0ada627f5
("virtio-net: fix race between ndo_open() and virtio_device_ready()"),
which did not ensure to set the DRIVER_OK status bit before modifying
the table.
Fixes: 06b636a1e2ad ("virtio-net: do not reset vlan filtering at set_features") Cc: qemu-stable@nongnu.org Reported-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Tested-by: Lei Yang <leiyang@redhat.com>
Message-Id: <20250727-vlan-v3-1-bbee738619b1@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 6071d13c6a37493a6b26e1609b09a98aa058038a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Hanna Czenczek [Thu, 24 Jul 2025 12:59:28 +0000 (14:59 +0200)]
vhost: Do not abort on log-stop error
Failing to stop logging in a vhost device is not exactly fatal. We can
log such an error, but there is no need to abort the whole qemu process
because of it.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20250724125928.61045-3-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d63c388dadb7717f6391e1bb7f11728c0c1a3e36) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Hanna Czenczek [Thu, 24 Jul 2025 12:59:27 +0000 (14:59 +0200)]
vhost: Do not abort on log-start error
Commit 3688fec8923 ("memory: Add Error** argument to .log_global_start()
handler") enabled vhost_log_global_start() to return a proper error, but
did not change it to do so; instead, it still aborts the whole process
on error.
This crash can be reproduced by e.g. killing a virtiofsd daemon before
initiating migration. In such a case, qemu should not crash, but just
make the attempted migration fail.
Buglink: https://issues.redhat.com/browse/RHEL-94534 Reported-by: Tingting Mao <timao@redhat.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20250724125928.61045-2-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit c1997099dc26d95eb9f2249f2894aabf4cf0bf8b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
virtio: fix off-by-one and invalid access in virtqueue_ordered_fill
Commit b44135daa372 introduced virtqueue_ordered_fill for
VIRTIO_F_IN_ORDER support but had a few issues:
* Conditional while loop used 'steps <= max_steps' but should've been
'steps < max_steps' since reaching steps == max_steps would indicate
that we didn't find an element, which is an error. Without this
change, the code would attempt to read invalid data at an index
outside of our search range.
* Incremented 'steps' using the next chain's ndescs instead of the
current one.
This patch corrects the loop bounds and synchronizes 'steps' and index
increments.
We also add a defensive sanity check against malicious or invalid
descriptor counts to avoid a potential infinite loop and DoS.
Fixes: b44135daa372 ("virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support") Reported-by: terrynini <terrynini38514@gmail.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com>
Message-Id: <20250721150208.2409779-1-jonah.palmer@oracle.com> Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 6fcf5ebafad65adc19a616260ca7dc90005785d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
On LoongArch64 system, the high 32 bit of 64 bit virtual address should be
0x00000[0-7]yyy or 0xffff8yyy. The bit from 47 to 63 should be all 0 or
all 1.
Function get_physical_address() only checks bit 48 to 63, there will be
problem with the following test case. On physical machine, there is bus
error report and program exits abnormally. However on qemu TCG system
emulation mode, the program runs normally. The virtual address
0xffff000000000000ULL + addr and addr are treated the same on TLB entry
checking. This patch fixes this issue.
Cc: qemu-stable@nongnu.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250714015446.746163-1-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit caab7ac83507e3e9a5fe2f37be5cfa759e766ba2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jay Chang [Tue, 1 Jul 2025 03:00:21 +0000 (11:00 +0800)]
target/riscv: Restrict midelegh access to S-mode harts
RISC-V AIA Spec states:
"For a machine-level environment, extension Smaia encompasses all added
CSRs and all modifications to interrupt response behavior that the AIA
specifies for a hart, over all privilege levels. For a supervisor-level
environment, extension Ssaia is essentially the same as Smaia except
excluding the machine-level CSRs and behavior not directly visible to
supervisor level."
Since midelegh is an AIA machine-mode CSR, add Smaia extension check in
aia_smode32 predicate.
Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Nutty Liu<liujingqi@lanxincomputing.com>
Message-ID: <20250701030021.99218-3-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 86bc3a0abf10072081cddd8dff25aa72c60e67b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jay Chang [Tue, 1 Jul 2025 03:00:20 +0000 (11:00 +0800)]
target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts
RISC-V Privileged Spec states:
"In harts with S-mode, the medeleg and mideleg registers must exist, and
setting a bit in medeleg or mideleg will delegate the corresponding trap
, when occurring in S-mode or U-mode, to the S-mode trap handler. In
harts without S-mode, the medeleg and mideleg registers should not
exist."
Add smode predicate to ensure these CSRs are only accessible when S-mode
is supported.
Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Nutty Liu<liujingqi@lanxincomputing.com>
Message-ID: <20250701030021.99218-2-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit e443ba03361b63218e6c3aa4f73d2cb5b9b1d372) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Yang Jialong [Mon, 28 Jul 2025 05:51:14 +0000 (13:51 +0800)]
intc/riscv_aplic: Fix target register read when source is inactive
The RISC-V Advanced interrupt Architecture:
4.5.16. Interrupt targets:
If interrupt source i is inactive in this domain, register target[i] is
read-only zero.
Signed-off-by: Yang Jialong <z_bajeer@yeah.net> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20250728055114.252024-1-z_bajeer@yeah.net> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit b6f1244678bebaf7e2c775cfc66d452f95678ebf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
pmp_is_in_range() prefers to match addresses within the interval
[start, end]. To archieve this, pmpaddrX is decremented during the end
address update.
In TOR mode, a rule is ignored if its start address is greater than or
equal to its end address.
However, if pmpaddrX is set to 0, this decrement operation causes the
calulated end address to wrap around to UINT_MAX. In this scenario, the
address guard for this PMP entry would become ineffective.
This patch addresses the issue by moving the guard check earlier,
preventing the problematic wraparound when pmpaddrX is zero.
Signed-off-by: Vac Chen <vacantron@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250706065554.42953-1-vacantron@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 77707bfdf871199bbee665e721ced961aaf3a798) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/riscv: do not call GETPC() in check_ret_from_m_mode()
GETPC() should always be called from the top level helper, e.g. the
first helper that is called by the translation code. We stopped doing
that in commit 3157a553ec, and then we introduced problems when
unwinding the exceptions being thrown by helper_mret(), as reported by
[1].
Call GETPC() at the top level helper and pass the value along.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250728170633.113384-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit e111ffe48b29ca8abd450af9ee5dd71af3f93536) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
A use-after-free bug was reported when booting a Linux kernel during the
pci setup phase. It's quite hard to reproduce (needs smp, and favored by
having several pci devices with BAR and specific Linux config, which
is Debian default one in this case).
After investigation (see the associated bug ticket), it appears that,
under specific conditions, we might access a cached AddressSpaceDispatch
that was reclaimed by RCU thread meanwhile.
In the Linux boot scenario, during the pci phase, memory region are
destroyed/recreated, resulting in exposition of the bug.
The core of the issue is that we cache the dispatch associated to
current cpu in cpu->cpu_ases[asidx].memory_dispatch. It is updated with
tcg_commit, which runs asynchronously on a given cpu.
At some point, we leave the rcu critial section, and the RCU thread
starts reclaiming it, but tcg_commit is not yet invoked, resulting in
the use-after-free.
It's not the first problem around this area, and commit 0d58c660689 [1]
("softmmu: Use async_run_on_cpu in tcg_commit") already tried to
address it. It did a good job, but it seems that we found a specific
situation where it's not enough.
This patch takes a simple approach: remove the cached value creating the
issue, and make sure we always get the current mapping for address
space, using address_space_to_dispatch(cpu->cpu_ases[asidx].as).
It's equivalent to qatomic_rcu_read(&as->current_map)->dispatch;
This is not really costly, we just need two dereferences,
including one atomic (rcu) read, which is negligible considering we are
already on mmu slow path anyway.
Note that tcg_commit is still needed, as it's taking care of flushing
TLB, removing previously mapped entries.
Another solution would be to cache directly values under the dispatch
(dispatch themselves are not ref counted), keep an active reference on
associated memory section, and release it when appropriate (tricky).
Given the time already spent debugging this area now and previously, I
strongly prefer eliminating the root of the issue, instead of adding
more complexity for a hypothetical performance gain. RCU is precisely
used to ensure good performance when reading data, so caching is not as
beneficial as it might seem IMHO.
target/mips: Only update MVPControl.EVP bit if executed by master VPE
According to the 'MIPS MT Application-Specific Extension' manual:
If the VPE executing the instruction is not a Master VPE,
with the MVP bit of the VPEConf0 register set, the EVP bit
is unchanged by the instruction.
Modify the DVPE/EVPE opcodes to only update the MVPControl.EVP bit
if executed on a master VPE.
Cc: qemu-stable@nongnu.org Reported-by: Hansni Bu Buglink: https://bugs.launchpad.net/qemu/+bug/1926277 Fixes: f249412c749 ("mips: Add MT halting and waking of VPEs") Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Message-ID: <20210427133343.159718-1-f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit e895095c78ab877d40df2dd31ee79d85757d963b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 25 Jul 2025 17:55:09 +0000 (18:55 +0100)]
linux-user/aarch64: Support TPIDR2_MAGIC signal frame record
FEAT_SME adds the TPIDR2 userspace-accessible system register, which
is used as part of the procedure calling standard's lazy saving
scheme for the ZA registers:
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#66the-za-lazy-saving-scheme
The Linux kernel has a signal frame record for saving
and restoring this value when calling signal handlers, but
we forgot to implement this. The result is that code which
tries to unwind an exception out of a signal handler will
not work correctly.
Add support for the missing record.
Cc: qemu-stable@nongnu.org Fixes: 78011586b90d1 ("target/arm: Enable SME for user-only") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250725175510.3864231-3-peter.maydell@linaro.org>
(cherry picked from commit 99870aff907b1c863cd32558b543f0ab0d0e74ba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 25 Jul 2025 17:55:08 +0000 (18:55 +0100)]
linux-user/aarch64: Clear TPIDR2_EL0 when delivering signals
A recent change to the kernel (Linux commit b376108e1f88
"arm64/fpsimd: signal: Clear TPIDR2 when delivering signals") updated
the signal-handler entry code to always clear TPIDR2_EL0.
This is necessary for the userspace ZA lazy saving scheme to work
correctly when unwinding exceptions across a signal boundary.
(For the essay-length description of the incorrect behaviour and
why this is the correct fix, see the commit message for the
kernel commit.)
Make QEMU also clear TPIDR2_EL0 on signal entry, applying the
equivalent bugfix to our implementation.
Note that getting this unwinding to work correctly also requires
changes to the userspace code, e.g. as implemented in gcc in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b5ffc8e75a8
This change is technically an ABI change; from the kernel's
point of view SME was never enabled (it was hidden behind
CONFIG_BROKEN) before the change. From QEMU's point of view
our SME-related signal handling was broken anyway as we weren't
saving and restoring TPIDR2_EL0.
Cc: qemu-stable@nongnu.org Fixes: 78011586b90d1 ("target/arm: Enable SME for user-only") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250725175510.3864231-2-peter.maydell@linaro.org>
(cherry picked from commit 3cdd990aa920ec8f2994b634f758dab4a86ac167) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Thu, 24 Jul 2025 23:10:12 +0000 (01:10 +0200)]
target/i386: fix width of third operand of VINSERTx128
Table A-5 of the Intel manual incorrectly lists the third operand of
VINSERTx128 as Wqq, but it is actually a 128-bit value. This is
visible when W is a memory operand close to the end of the page.
Fixes the recently-added poly1305_kunit test in linux-next.
(No testcase yet, but I plan to modify test-avx2 to use memory
close to the end of the page. This would work because the test
vectors correctly have the memory operand as xmm2/m128).
Reported-by: Eric Biggers <ebiggers@kernel.org> Tested-by: Eric Biggers <ebiggers@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: qemu-stable@nongnu.org Fixes: 79068477686 ("target/i386: reimplement 0x0f 0x3a, add AVX", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit feea87cd6b645d5166bdd304aac88f47f63dc2ef) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In case of multiple chunks, code in qxl_unpack_chunks() takes size of the
wrong (next in the chain) chunk, instead of using current chunk size.
This leads to wrong number of bytes being copied, and to crashes if next
chunk size is larger than the current one.
Based on the code by Gao Yong.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1628 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit b8882becd572d3afb888c836a6ffc7f92c17d1c5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 21 Jul 2025 09:07:53 +0000 (10:07 +0100)]
host-utils: Drop workaround for buggy Apple Clang __builtin_subcll()
In commit b0438861efe ("host-utils: Avoid using __builtin_subcll on
buggy versions of Apple Clang") we added a workaround for a bug in
Apple Clang 14 where its __builtin_subcll() implementation was wrong.
This bug was only present in Apple Clang 14, not in upstream clang,
and is not present in Apple Clang versions 15 and newer.
Since commit 4e035201 we have required at least Apple Clang 15, so we
no longer build with the buggy versions. We can therefore drop the
workaround. This is effectively a revert of b0438861efe.
This should not be backported to stable branches, which may still
need to support Apple Clang 14.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3030 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250714145033.1908788-1-peter.maydell@linaro.org
(cherry picked from commit e74aad9f81cc2bfee2057086610e21bd98e9c5a5)
(Mjt: 10.0 already requres clang 15+, so it's okay to backport
this change to 10.0 branch) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit a2260983c655 ("hvf: arm: Add support for GICv3") added GICv3 support
by implementing emulation for a few system registers. ICC_RPR_EL1 was
defined but not plugged in the sysreg handlers (for no good reason).
Fix it.
Fixes: a2260983c655 ("hvf: arm: Add support for GICv3") Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250714160139.10404-3-zenghui.yu@linux.dev Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e6da704b711d5d731e4d933ad56cbbc25ee0a825) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 21 Jul 2025 09:07:52 +0000 (10:07 +0100)]
target/arm: Correct encoding of Debug Communications Channel registers
We don't implement the Debug Communications Channel (DCC), but
we do attempt to provide dummy versions of its system registers
so that software that tries to access them doesn't fall over.
However, we got the tx/rx register definitions wrong. These
should be:
AArch32:
DBGDTRTX p14 0 c0 c5 0 (on writes)
DBGDTRRX p14 0 c0 c5 0 (on reads)
AArch64:
DBGDTRTX_EL0 2 3 0 5 0 (on writes)
DBGDTRRX_EL0 2 3 0 5 0 (on reads)
DBGDTR_EL0 2 3 0 4 0 (reads and writes)
where DBGDTRTX and DBGDTRRX are effectively different names for the
same 32-bit register, which has tx behaviour on writes and rx
behaviour on reads. The AArch64-only DBGDTR_EL0 is a 64-bit wide
register whose top and bottom halves map to the DBGDTRRX and DBGDTRTX
registers.
Currently we have just one cpreg struct, which:
* calls itself DBGDTR_EL0
* uses the DBGDTRTX_EL0/DBGDTRRX_EL0 encoding
* is marked as ARM_CP_STATE_BOTH but has the wrong opc1
value for AArch32
* is implemented as RAZ/WI
Correct the encoding so:
* we name the DBGDTRTX/DBGDTRRX register correctly
* we split it into AA64 and AA32 versions so we can get the
AA32 encoding right
* we implement DBGDTR_EL0 at its correct encoding
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2986 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250708141049.778361-1-peter.maydell@linaro.org
(cherry picked from commit 655659a74a36b63e33d2dc969d3c44beb1b008b3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When a VNC client sends a "set pixel format" message, the
'client_endian' field will get initialized, however, it is
valid to omit this message if the client wants to use the
server's native pixel format. In the latter scenario nothing
is initializing the 'client_endian' field, so it remains set
to 0, matching neither G_LITTLE_ENDIAN nor G_BIG_ENDIAN. This
then results in pixel format conversion routines taking the
wrong code paths.
This problem existed before the 'client_be' flag was changed
into the 'client_endian' value, but the lack of initialization
meant it semantically defaulted to little endian, so only big
endian systems would potentially be exposed to incorrect pixel
translation.
The 'virt-viewer' / 'remote-viewer' apps always send a "set
pixel format" message so aren't exposed to any problems, but
the classical 'vncviewer' app will show the problem easily.
Fixes: 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd Reported-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 3ac6daa9e1c5d7dae2a3cd1c6a388174b462f3e8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 14 Jul 2025 16:55:20 +0000 (17:55 +0100)]
hw/net/npcm_gmac.c: Send the right data for second packet in a row
The transmit loop in gmac_try_send_next_packet() is constructed in a
way that means it will send incorrect data if it it sends more than
one packet.
The function assembles the outbound data in a dynamically allocated
block of memory which is pointed to by tx_send_buffer. We track the
first point in this block of memory which is not yet used with the
prev_buf_size offset, initially zero. We track the size of the
packet we're sending with the length variable, also initially zero.
As we read chunks of data out of guest memory, we write them to
tx_send_buffer[prev_buf_size], and then increment both prev_buf_size
and length. (We might dynamically reallocate the buffer if needed.)
When we send a packet, we checksum and send length bytes, starting at
tx_send_buffer, and then we reset length to 0. This gives the right
data for the first packet. But we don't reset prev_buf_size. This
means that if we process more descriptors with further data for the
next packet, that data will continue to accumulate at offset
prev_buf_size, i.e. after the data for the first packet. But when
we transmit that second packet, we send length bytes from
tx_send_buffer, so we will send a packet which has the length of the
second packet but the data of the first one.
The fix for this is to also clear prev_buf_size after the packet has
been sent -- we never need the data from packet one after we've sent
it, so we can write packet two's data starting at the beginning of
the buffer.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 871a6e5b339f0b5e71925ec7d3f452944a1c82d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 14 Jul 2025 08:19:36 +0000 (10:19 +0200)]
target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
KVM emulates the ARCH_CAPABILITIES on x86 for both Intel and AMD
cpus, although the IA32_ARCH_CAPABILITIES MSR is an Intel-specific
MSR and it makes no sense to emulate it on AMD.
As a consequence, VMs created on AMD with qemu -cpu host and using
KVM will advertise the ARCH_CAPABILITIES feature and provide the
IA32_ARCH_CAPABILITIES MSR. This can cause issues (like Windows BSOD)
as the guest OS might not expect this MSR to exist on such cpus (the
AMD documentation specifies that ARCH_CAPABILITIES feature and MSR
are not defined on the AMD architecture).
A fix was proposed in KVM code, however KVM maintainers don't want to
change this behavior that exists for 6+ years and suggest changes to be
done in QEMU instead. Therefore, hide the bit from "-cpu host":
migration of -cpu host guests is only possible between identical host
kernel and QEMU versions, therefore this is not a problematic breakage.
If a future AMD machine does include the MSR, that would re-expose the
Windows guest bug; but it would not be KVM/QEMU's problem at that
point, as we'd be following a genuine physical CPU impl.
Reported-by: Alexandre Chartre <alexandre.chartre@oracle.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d3a24134e37d57abd3e7445842cda2717f49e96d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Zhao Liu [Mon, 14 Jul 2025 08:08:59 +0000 (16:08 +0800)]
i386/cpu: Honor maximum value for CPUID.8000001DH.EAX[25:14]
CPUID.8000001DH:EAX[25:14] is "NumSharingCache", and the number of
logical processors sharing this cache is the value of this field
incremented by 1. Because of its width limitation, the maximum value
currently supported is 4095.
Though at present Q35 supports up to 4096 CPUs, by constructing a
specific topology, the width of the APIC ID can be extended beyond 12
bits. For example, using `-smp threads=33,cores=9,modules=9` results in
a die level offset of 6 + 4 + 4 = 14 bits, which can also cause
overflow. Check and honor the maximum value as CPUID.04H did.
i386/cpu: Fix overflow of cache topology fields in CPUID.04H
According to SDM, CPUID.0x4:EAX[31:26] indicates the Maximum number of
addressable IDs for processor cores in the physical package. If we
launch over 64 cores VM, the 6-bit field will overflow, and the wrong
core_id number will be reported.
Since the HW reports 0x3f when the intel processor has over 64 cores,
limit the max value written to EAX[31:26] to 63, so max num_cores should
be 64.
For EAX[14:25], though at present Q35 supports up to 4096 CPUs, by
constructing a specific topology, the width of the APIC ID can be
extended beyond 12 bits. For example, using `-smp threads=33,cores=9,
modules=9` results in a die level offset of 6 + 4 + 4 = 14 bits, which
can also cause overflow. check and honor the maximum value for
EAX[14:25] as well.
In addition, for host-cache-info case, also apply the same checks and
fixes.
Michael Tokarev [Thu, 17 Jul 2025 03:23:26 +0000 (06:23 +0300)]
i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
The legacy topology enumerated by CPUID.1.EBX[23:16] is defined in SDM
Vol2:
Bits 23-16: Maximum number of addressable IDs for logical processors in
this physical package.
When threads_per_socket > 255, it will 1) overwrite bits[31:24] which is
apic_id, 2) bits [23:16] get truncated.
Specifically, if launching the VM with -smp 256, the value written to
EBX[23:16] is 0 because of data overflow. If the guest only supports
legacy topology, without V2 Extended Topology enumerated by CPUID.0x1f
or Extended Topology enumerated by CPUID.0x0b to support over 255 CPUs,
the return of the kernel invoking cpu_smt_allowed() is false and APs
(application processors) will fail to bring up. Then only CPU 0 is online,
and others are offline.
For example, launch VM via:
qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split \
-cpu qemu64,cpuid-0xb=off -smp 256 -m 32G \
-drive file=guest.img,if=none,id=virtio-disk0,format=raw \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=1 --nographic
To avoid this issue caused by overflow, limit the max value written to
EBX[23:16] to 255 as the HW does.
Cc: qemu-stable@nongnu.org Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Qian Wen <qian.wen@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250714080859.1960104-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a62fef58299562aae6667b8d8552247423e886b3)
(Mjt: fixup for 10.0.x series due to missing v10.0.0-2217-gf985a1195b
"i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Akihiko Odaki [Tue, 3 Jun 2025 09:18:28 +0000 (18:18 +0900)]
ui/vnc: Do not copy z_stream
vnc_worker_thread_loop() copies z_stream stored in its local VncState to
the persistent VncState, and the copied one is freed with deflateEnd()
later. However, deflateEnd() refuses to operate with a copied z_stream
and returns Z_STREAM_ERROR, leaking the allocated memory.
Avoid copying the zlib state to fix the memory leak.
Fixes: bd023f953e5e ("vnc: threaded VNC server") Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20250603-zlib-v3-1-20b857bd8d05@rsg.ci.i.u-tokyo.ac.jp>
(cherry picked from commit aef22331b5a4670f42638a5f63a26e93bf779aae) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
vhost: Fix used memslot tracking when destroying a vhost device
When we unplug a vhost device, we end up calling vhost_dev_cleanup()
where we do a memory_listener_unregister().
This memory_listener_unregister() call will end up disconnecting the
listener from the address space through listener_del_address_space().
In that process, we effectively communicate the removal of all memory
regions from that listener, resulting in region_del() + commit()
callbacks getting triggered.
So in case of vhost, we end up calling vhost_commit() with no remaining
memory slots (0).
In vhost_commit() we end up overwriting the global variables
used_memslots / used_shared_memslots, used for detecting the number
of free memslots. With used_memslots / used_shared_memslots set to 0
by vhost_commit() during device removal, we'll later assume that the
other vhost devices still have plenty of memslots left when calling
vhost_get_free_memslots().
Let's fix it by simply removing the global variables and depending
only on the actual per-device count.
Easy to reproduce by adding two vhost-user devices to a VM and then
hot-unplugging one of them.
While at it, detect unexpected underflows in vhost_get_free_memslots()
and issue a warning.
Reported-by: yuanminghao <yuanmh12@chinatelecom.cn> Link: https://lore.kernel.org/qemu-devel/20241121060755.164310-1-yuanmh12@chinatelecom.cn/ Fixes: 2ce68e4cf5be ("vhost: add vhost_has_free_slot() interface") Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20250603111336.1858888-1-david@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9f749129e2629b19f424df106c92c5a5647e396c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Wed, 25 Jun 2025 08:50:19 +0000 (10:50 +0200)]
file-posix: Fix aio=threads performance regression after enablign FUA
For aio=threads, we're currently not implementing REQ_FUA in any useful
way, but just do a separate raw_co_flush_to_disk() call. This changes
behaviour compared to the old state, which used bdrv_co_flush() with its
optimisations. As a quick fix, call bdrv_co_flush() again like before.
Eventually, we can use pwritev2() to make use of RWF_DSYNC if available,
but we'll still have to keep this code path as a fallback, so this fix
is required either way.
While the fix itself is a one-liner, some new graph locking annotations
are needed to convince TSA that the locking is correct.
Cc: qemu-stable@nongnu.org Fixes: 984a32f17e8d ("file-posix: Support FUA writes") Buglink: https://issues.redhat.com/browse/RHEL-96854 Reported-by: Tingting Mao <timao@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250625085019.27735-1-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d402da1360c2240e81f0e5fc80ddbfc6238e0da8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ethan Milon [Tue, 17 Jun 2025 15:04:27 +0000 (15:04 +0000)]
amd_iommu: Fix truncation of oldval in amdvi_writeq
The variable `oldval` was incorrectly declared as a 32-bit `uint32_t`.
This could lead to truncation and incorrect behavior where the upper
read-only 32 bits are significant.
Fix the type of `oldval` to match the return type of `ldq_le_p()`.
Cc: qemu-stable@nongnu.org Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Ethan Milon <ethan.milon@eviden.com>
Message-Id: <20250617150427.20585-9-alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5788929e05e18ed5f76dc8ade4210f022c9ba5a1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250617150427.20585-8-alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5959b641c98b5ae9677e2c1d89902dac31b344d9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
amd_iommu: Fix mask to retrieve Interrupt Table Root Pointer from DTE
Fix an off-by-one error in the definition of AMDVI_IR_PHYS_ADDR_MASK. The
current definition masks off the most significant bit of the Interrupt Table
Root ptr i.e. it only generates a mask with bits [50:6] set. See the AMD I/O
Virtualization Technology (IOMMU) Specification for the Interrupt Table
Root Pointer[51:6] field in the Device Table Entry format.
Cc: qemu-stable@nongnu.org Fixes: b44159fe0078 ("x86_iommu/amd: Add interrupt remap support when VAPIC is not enabled") Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250617150427.20585-6-alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 123cf4bdd378f746dfa2f5415ba084148dded3e3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
amd_iommu: Fix masks for various IOMMU MMIO Registers
Address various issues with definitions of the MMIO registers e.g. for the
Device Table Address Register, the size mask currently encompasses reserved
bits [11:9], so change it to only extract the bits [8:0] encoding size.
Convert masks to use GENMASK64 for consistency, and make unrelated
definitions independent.
Cc: qemu-stable@nongnu.org Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250617150427.20585-5-alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 108e10ff69099c3ebe147f505246be7c2ad2a499) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The DTE validation method verifies that all bits in reserved DTE fields are
unset. Update them according to the latest definition available in AMD I/O
Virtualization Technology (IOMMU) Specification - Section 2.2.2.1 Device
Table Entry Format. Remove the magic numbers and use a macro helper to
generate bitmasks covering the specified ranges for better legibility.
Note that some reserved fields specify that events are generated when they
contain non-zero bits, or checks are skipped under certain configurations.
This change only updates the reserved masks, checks for special conditions
are not yet implemented.
Cc: qemu-stable@nongnu.org Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250617150427.20585-4-alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit ff3dcb3bf652912466dcc1cd10d3267f185c212e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
amd_iommu: Fix Device ID decoding for INVALIDATE_IOTLB_PAGES command
The DeviceID bits are extracted using an incorrect offset in the call to
amdvi_iotlb_remove_page(). This field is read (correctly) earlier, so use
the value already retrieved for devid.
Cc: qemu-stable@nongnu.org Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250617150427.20585-3-alejandro.j.jimenez@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit c63b8d1425ba8b3b08ee4f7346457fd8a7f12a24) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
amd_iommu: Fix Miscellaneous Information Register 0 encoding
The definitions encoding the maximum Virtual, Physical, and Guest Virtual
Address sizes supported by the IOMMU are using incorrect offsets i.e. the
VASize and GVASize offsets are switched. The value in the GVAsize field is
also modified, since it was incorrectly encoded.
Cc: qemu-stable@nongnu.org Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU") Co-developed-by: Ethan MILON <ethan.milon@eviden.com> Signed-off-by: Ethan MILON <ethan.milon@eviden.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Message-Id: <20250617150427.20585-2-alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 091c7d7924f33781c2fb8e7297dc54971e0c3785) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Akihiko Odaki [Fri, 30 May 2025 05:18:53 +0000 (14:18 +0900)]
virtio-net: Add queues for RSS during migration
virtio_net_pre_load_queues() inspects vdev->guest_features to tell if
VIRTIO_NET_F_RSS or VIRTIO_NET_F_MQ is enabled to infer the required
number of queues. This works for VIRTIO_NET_F_MQ but it doesn't for
VIRTIO_NET_F_RSS because only the lowest 32 bits of vdev->guest_features
is set at the point and VIRTIO_NET_F_RSS uses bit 60 while
VIRTIO_NET_F_MQ uses bit 22.
Instead of inferring the required number of queues from
vdev->guest_features, use the number loaded from the vm state. This
change also has a nice side effect to remove a duplicate peer queue
pair change by circumventing virtio_net_set_multiqueue().
Also update the comment in include/hw/virtio/virtio.h to prevent an
implementation of pre_load_queues() from refering to any fields being
loaded during migration by accident in the future.
Fixes: 8c49756825da ("virtio-net: Add only one queue pair when realizing") Tested-by: Lei Yang <leiyang@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit adda0ad56bd28d5a809051cbd190fda5798ec4e4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Wed, 2 Jul 2025 06:03:19 +0000 (08:03 +0200)]
accel/kvm: Adjust the note about the minimum required kernel version
Since commit 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and
KVM_CAP_IOEVENTFD_ANY_LENGTH") we require at least kernel 4.5 to
be able to use KVM. Adjust the upgrade_note accordingly.
While we're at it, remove the text about kvm-kmod and the
SourceForge URL since this is not actively maintained anymore.
Fixes: 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and KVM_CAP_IOEVENTFD_ANY_LENGTH") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit f180e367fce44b336105a11a62edf9610b6b2a06)
This has two problems:
(1) it doesn't check errors, which Coverity complains about
(2) we use F_GETFL when we mean F_GETFD
Deal with both of these problems by using qemu_set_cloexec() instead.
That function will assert() if the fcntls fail, which is fine (we are
inside fork_start()/fork_end() so we know nothing can mess around
with our file descriptors here, and we just got this one from
pidfd_open()).
(As we are touching the if() statement here, we correct the
indentation.)
Coverity: CID 1508111 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250711141217.1429412-1-peter.maydell@linaro.org>
(cherry picked from commit d6390204c61e148488f034d1f79be35cd3318d93) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Chaney, Ben [Mon, 16 Jun 2025 20:56:50 +0000 (20:56 +0000)]
migration: Don't sync volatile memory after migration completes
Syncing volatile memory provides no benefit, instead it can cause
performance issues in some cases. Only sync memory that is marked as
non-volatile after migration completes on destination.
Geoffrey Thomas [Fri, 14 Mar 2025 12:47:42 +0000 (08:47 -0400)]
linux-user: Hold the fd-trans lock across fork
If another thread is holding target_fd_trans_lock during a fork,
then the lock becomes permanently locked in the child and the
emulator deadlocks at the next interaction with the fd-trans table.
As with other locks, acquire the lock in fork_start() and release
it in fork_end().
Cc: qemu-stable@nongnu.org Signed-off-by: Geoffrey Thomas <geofft@ldpreload.com> Fixes: c093364f4d91 "fd-trans: Fix race condition on reallocation of the translation table."
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2846 Buglink: https://github.com/astral-sh/uv/issues/6105 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250314124742.4965-1-geofft@ldpreload.com>
(cherry picked from commit e4e839b2eeea5745c48ce47144c7842eb7cd455f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 10 Jul 2025 16:43:54 +0000 (17:43 +0100)]
linux-user: Check for EFAULT failure in nanosleep
target_to_host_timespec() returns an error if the memory the guest
passed us isn't actually readable. We check for this everywhere
except the callsite in the TARGET_NR_nanosleep case, so this mistake
was caught by a Coverity heuristic.
Add the missing error checks to the calls that convert between the
host and target timespec structs.
Coverity: CID 1507104 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250710164355.1296648-1-peter.maydell@linaro.org>
(cherry picked from commit c4828cb8502d0b2adc39b9cde93df7d2886df897) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 10 Jul 2025 11:31:23 +0000 (12:31 +0100)]
linux-user: Implement fchmodat2 syscall
The fchmodat2 syscall is new from Linux 6.6; it is like the
existing fchmodat syscall except that it takes a flags parameter.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3019 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250710113123.1109461-1-peter.maydell@linaro.org>
(cherry picked from commit 6a3e132a1be8c9e649967a4eb341d00731be7f51) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 4 Jul 2025 16:56:36 +0000 (17:56 +0100)]
target/arm: Don't enforce NSE,NS check for EL3->EL3 returns
In the Arm ARM, rule R_TYTWB that defines illegal exception return cases
includes the case:
If FEAT_RME is implemented, then if SCR_EL3.{NSE, NS} is {1, 0}, an
exception return from EL3 to a lower Exception level
Our implementation of this check fails to check that the
return is to a lower exception level, so it will incorrectly fire on
EL3->EL3 exception returns.
Fix the check condition. This requires us to move it further
down in the function to a point where we know the new_el value.
Fixes: 35aa6715ddcd9 ("target/arm: Catch illegal-exception-return from EL3 with bad NSE/NS") Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3016 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250704165636.261888-1-peter.maydell@linaro.org
(cherry picked from commit c563cd7e61d074f58eef413322144461dd243716) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Mark Cave-Ayland [Wed, 11 Jun 2025 13:03:15 +0000 (14:03 +0100)]
target/i386: fix TB exit logic in gen_movl_seg() when writing to SS
Before commit e54ef98c8a ("target/i386: do not trigger IRQ shadow for LSS"), any
write to SS in gen_movl_seg() would cause a TB exit. The changes introduced by
this commit were intended to restrict the DISAS_EOB_INHIBIT_IRQ exit to the case
where inhibit_irq is true, but missed that a DISAS_EOB_NEXT exit can still be
required when writing to SS and inhibit_irq is false.
Comparing the PE(s) && !VM86(s) section with the logic in x86_update_hflags(), we
can see that the DISAS_EOB_NEXT exit is still required for the !CODE32 case when
writing to SS in gen_movl_seg() because any change to the SS flags can affect
hflags. Similarly we can see that the existing CODE32 case is still correct since
a change to any of DS, ES and SS can affect hflags. Finally for the
gen_op_movl_seg_real() case an explicit TB exit is not needed because the segment
register selector does not affect hflags.
Update the logic in gen_movl_seg() so that a write to SS with inhibit_irq set to
false where PE(s) && !VM86(s) will generate a DISAS_EOB_NEXT exit along with the
inline comment. This has the effect of allowing Win98SE to boot in QEMU once
again.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: e54ef98c8a ("target/i386: do not trigger IRQ shadow for LSS")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2987 Link: https://lore.kernel.org/r/20250611130315.383151-1-mark.cave-ayland@ilande.co.uk Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 0f1d6606c28d0ae81a1b311972c5c54e5e867bf0) Fixes: 0f1d6606c2 ("target/i386: do not trigger IRQ shadow for LSS" in 10.0.x) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
We missed the instructions UDEF when the vector size is too small.
We missed marking the instructions non-streaming with SME.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250704142112.1018902-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e6ffd009c7710a8cc98094897fa0af609c114683) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Do not assume SME implies SVE. Ensure that the non-streaming
check is present along the SME path, since it is not implied
by sme_*_enabled_check.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250704142112.1018902-3-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b4b2e070f41dd8774a70c6186141678558d79a38) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Kevin Wolf [Wed, 25 Jun 2025 08:27:51 +0000 (10:27 +0200)]
hw/s390x/ccw-device: Fix memory leak in loadparm setter
Commit bdf12f2a fixed the setter for the "loadparm" machine property,
which gets a string from a visitor, passes it to s390_ipl_fmt_loadparm()
and then forgot to free it. It left another instance of the same problem
unfixed in the "loadparm" device property. Fix it.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250625082751.24896-1-kwolf@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 78e3781541209b3dcd6f4bb66adf3a3e504b88a4)
(Mjt: bdf12f2a is 8efe1592 in stable-10.0 branch) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Yiwei Zhang [Fri, 27 Jun 2025 11:25:11 +0000 (12:25 +0100)]
virtio-gpu: support context init multiple timeline
Venus and later native contexts have their own fence context along with
multiple timelines within. Fences wtih VIRTIO_GPU_FLAG_INFO_RING_IDX in
the flags must be dispatched to be created on the target context. Fence
signaling also has to be handled on the specific timeline within that
target context.
Before this change, venus fencing is completely broken if the host
driver doesn't support implicit fencing with external memory objects.
Frames can go backwards along with random artifacts on screen if the
host driver doesn't attach an implicit fence to the render target. The
symptom could be hidden by certain guest wsi backend that waits on a
venus native VkFence object for the actual payload with limited present
modes or under special configs. e.g. x11 mailbox or xwayland.
After this change, everything related to venus fencing starts making
sense. Confirmed this via guest and host side perfetto tracing.
Cc: qemu-stable@nongnu.org Fixes: 94d0ea1c1928 ("virtio-gpu: Support Venus context") Signed-off-by: Yiwei Zhang <zzyiwei@gmail.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-Id: <20250518152651.334115-1-zzyiwei@gmail.com>
[AJB: remove version history from commit message] Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250627112512.1880708-16-alex.bennee@linaro.org>
(cherry picked from commit 1fa2ffdbec55d84326e22f046bc3e26322836f5a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
on qemu we got an aborted error
**
ERROR:../target/loongarch/tcg/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
Bail out! ERROR:../target/loongarch/tcg/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached
Aborted (core dumped)
but on 3A600/3A5000 we got a "Illegal instruction" error.
Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250603024810.350510-1-gaosong@loongson.cn>
(cherry picked from commit e7788da9860c97920c19fa1150806186513ef256) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
J. Neuschäfer [Fri, 13 Jun 2025 15:59:32 +0000 (17:59 +0200)]
linux-user/arm: Fix return value of SYS_cacheflush
Although the emulated cacheflush syscall does nothing, it still needs to
return zero to indicate success.
Cc: qemu-stable@nongnu.org Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Message-id: 20250613-cache-v1-1-ee9f4a9ba81b@gmx.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 5ad2b1f443a96444cf3e7a2fbe17aae696201012) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 5 Jun 2025 14:18:01 +0000 (15:18 +0100)]
hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions
The AN500 application note documents that it configures the Cortex-M7
CPU to have 16 MPU regions. We weren't doing this in our emulation,
so the CPU had only the default 8 MPU regions. Set the mpu-ns-regions
property to 16 for this board.
This bug doesn't affect any of the other board types we model in
this source file, because they all use either the Cortex-M3 or
Cortex-M4. Those CPUs do not have an RTL configurable number of
MPU regions, and always provide 8 regions if the MPU is built in.
Cc: qemu-stable@nongnu.org Reported-by: Corentin GENDRE <cocotroupe20@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250605141801.1083266-1-peter.maydell@linaro.org
(cherry picked from commit cd38e638c43e4d5d3fd65dd4529c2e6153c9c408) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Ethan Chen [Fri, 6 Jun 2025 09:57:28 +0000 (17:57 +0800)]
qemu-options.hx: Fix reversed description of icount sleep behavior
The documentation for the -icount option incorrectly describes the behavior
of the sleep suboption. Based on the actual implementation and system
behavior, the effects of sleep=on and sleep=off were inadvertently reversed.
This commit updates the description to reflect their intended functionality.
Cc: qemu-stable@nongnu.org Fixes: fa647905e6ba ("qemu-options.hx: Fix minor issues in icount documentation") Signed-off-by: Ethan Chen <ethan84@andestech.com>
Message-id: 20250606095728.3672832-1-ethan84@andestech.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e372214e663a4370fe064f7867f402eade37357e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
hw/arm/virt: Check bypass iommu is not set for iommu-map DT property
default_bus_bypass_iommu tells us whether the bypass_iommu is set
for the default PCIe root bus. Make sure we check that before adding
the "iommu-map" DT property.
Cc: qemu-stable@nongnu.org Fixes: 6d7a85483a06 ("hw/arm/virt: Add default_bus_bypass_iommu machine option") Suggested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Donald Dutile <ddutile@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20250602114655.42920-1-shameerali.kolothum.thodi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit f5ec751ee70d7960a97c6c675f69e924d82dc60d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bibo Mao [Wed, 4 Jun 2025 06:55:01 +0000 (14:55 +0800)]
hw/loongarch/virt: Fix big endian support with MCFG table
With API build_mcfg(), it is not necessary with parameter structure
AcpiMcfgInfo to convert to little endian since it is directly used
with host native endian.
Here remove endian conversion before calling function build_mcfg().
With this patch, bios-tables-test passes to run on big endian host
machine S390.
Fixes: 735143f10d3e ("hw/loongarch: Add acpi ged support") Cc: qemu-stable@nongnu.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20250604065502.1114098-2-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 9c55c03c05c1899521ff0c991b9296633d759890) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Fiona Ebner [Fri, 23 May 2025 07:02:11 +0000 (09:02 +0200)]
hw/core/qdev-properties-system: Add missing return in set_drive_helper()
Currently, changing the 'drive' property of e.g. a scsi-hd object will
result in an assertion failure if the aio context of the block node
it's replaced with doesn't match the current aio context:
The problematic scenario is already detected, but a 'return' statement
was missing.
Cc: qemu-stable@nongnu.org Fixes: d1a58c176a ("qdev: allow setting drive property for realized device") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20250523070211.280498-1-f.ebner@proxmox.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit eef2dd03f948a512499775043bdc0c5c88d8a2dd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Stefan Hajnoczi [Thu, 29 May 2025 20:31:47 +0000 (16:31 -0400)]
iotests: fix 240
Commit 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
removed the limitation that virtio-scsi devices must successfully set
the AioContext on their BlockBackends. This was made possible thanks to
the QEMU multi-queue block layer.
This change broke qemu-iotests 240, which checks that adding a
virtio-scsi device with a drive that is already in another AioContext
will fail.
Update the test to take the relaxed behavior into account. I considered
removing this test case entirely, but the code coverage still seems
valuable.
Fixes: 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250529203147.180338-1-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2e887187454e57d04522099d4f04d17137d6e05c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:26 +0000 (07:44 +0200)]
hw/audio/asc: fix SIGSEGV in asc_realize()
AUD_open_out() may fail and return NULL. This may then lead to
a segmentation fault in memset() below. The memset() behaviour
is undefined if the pointer to the destination object is a null
pointer.
Add the missing error handling code.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20250515054429.7385-4-vr_qemu@t-online.de>
(cherry picked from commit d009f26a54f573468be721590a19350c224bc730) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:25 +0000 (07:44 +0200)]
audio: fix size calculation in AUD_get_buffer_size_out()
The buffer size calculated by AUD_get_buffer_size_out() is often
incorrect. sw->hw->samples * sw->hw->info.bytes_per_frame is the
size of the mixing engine buffer in audio frames multiplied by
the size of one frame of the audio backend. Due to resampling or
format conversion, the size of the frontend buffer can differ
significantly.
Return the correct buffer size when the mixing engine is used.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20250515054429.7385-3-vr_qemu@t-online.de>
(cherry picked from commit ccb4fec0e5f233cb61a83b3af59ae11716ea06c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Volker Rümelin [Thu, 15 May 2025 05:44:24 +0000 (07:44 +0200)]
audio: fix SIGSEGV in AUD_get_buffer_size_out()
As far as the emulated audio devices are concerned the pointer
returned by AUD_open_out() is an opaque handle. This includes
the NULL pointer. In this case, AUD_get_buffer_size_out() should
return a sensible buffer size instead of triggering a segmentation
fault. All other public AUD_*_out() and audio_*_out() functions
handle this case.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20250515054429.7385-2-vr_qemu@t-online.de>
(cherry picked from commit 5ddd6c8dc849b4af44bd06840c9133d64e62c27c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Vasant Hegde [Fri, 16 May 2025 10:05:35 +0000 (15:35 +0530)]
hw/i386/amd_iommu: Fix xtsup when vcpus < 255
If vCPUs > 255 then x86 common code (x86_cpus_init()) call kvm_enable_x2apic().
But if vCPUs <= 255 then the common code won't calls kvm_enable_x2apic().
This is because commit 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM
checks on XTSup feature") removed the call to kvm_enable_x2apic when xtsup
is "on", which break things when guest is booted with x2apic mode and
there are <= 255 vCPUs.
Fix this by adding back kvm_enable_x2apic() call when xtsup=on.
Sairaj Kodilkar [Fri, 16 May 2025 10:05:34 +0000 (15:35 +0530)]
hw/i386/amd_iommu: Fix device setup failure when PT is on.
Commit c1f46999ef506 ("amd_iommu: Add support for pass though mode")
introduces the support for "pt" flag by enabling nodma memory when
"pt=off". This allowed VFIO devices to successfully register notifiers
by using nodma region.
But, This also broke things when guest is booted with the iommu=nopt
because, devices bypass the IOMMU and use untranslated addresses (IOVA) to
perform DMA reads/writes to the nodma memory region, ultimately resulting in
a failure to setup the devices in the guest.
Fix the above issue by always enabling the amdvi_dev_as->iommu memory region.
But this will once again cause VFIO devices to fail while registering the
notifiers with AMD IOMMU memory region.
Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20250516100535.4980-2-sarunkod@amd.com> Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
(cherry picked from commit 31753d5a336fbb4e9246397f4b90b6f611f27f22) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bernhard Beschow [Mon, 26 May 2025 20:38:20 +0000 (22:38 +0200)]
hw/i386/pc_piix: Fix RTC ISA IRQ wiring of isapc machine
Commit 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
attempted to refactor RTC IRQ wiring which was previously done in
pc_basic_device_init() but forgot about the isapc machine. Fix this by
wiring in the code section dedicated exclusively to the isapc machine.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2961 Fixes: 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
cc: qemu-stable Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Message-Id: <20250526203820.1853-1-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 0b006153b7ec66505cb2d231235aa19ca5d2ce37) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Huaitong Han [Thu, 22 May 2025 10:05:48 +0000 (18:05 +0800)]
vhost: Don't set vring call if guest notifier is unused
The vring call fd is set even when the guest does not use MSI-X (e.g., in the
case of virtio PMD), leading to unnecessary CPU overhead for processing
interrupts.
The commit 96a3d98d2c("vhost: don't set vring call if no vector") optimized the
case where MSI-X is enabled but the queue vector is unset. However, there's an
additional case where the guest uses INTx and the INTx_DISABLED bit in the PCI
config is set, meaning that no interrupt notifier will actually be used.
In such cases, the vring call fd should also be cleared to avoid redundant
interrupt handling.
Fixes: 96a3d98d2c("vhost: don't set vring call if no vector") Reported-by: Zhiyuan Yuan <yuanzhiyuan@chinatelecom.cn> Signed-off-by: Jidong Xia <xiajd@chinatelecom.cn> Signed-off-by: Huaitong Han <hanht2@chinatelecom.cn>
Message-Id: <20250522100548.212740-1-hanht2@chinatelecom.cn> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a9403bfcd93025df7b1924d0cf34fbc408955b33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc: fix tight palette pixel encoding for 8/16-bpp formats
When sending a tight rectangle with the palette filter, if the client
format was 8/16bpp, the colours on big endian hosts are not set as
we're sending the wrong bytes. We must first cast the 32-bit colour
to a 16/8-bit value, and then send the result.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 63d320909220a90647c484263ae5e2f26eb54587) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc: take account of client byte order in pixman format
The set_pixel_conversion() method is responsible for determining whether
the VNC client pixel format matches the server format, and thus whether
we can use the fast path "copy" impl for sending pixels, or must use
the generic impl with bit swizzling.
The VNC server format is set at build time to VNC_SERVER_FB_FORMAT,
which corresponds to PIXMAN_x8r8g8b8.
The qemu_pixman_get_format() method is then responsible for converting
the VNC pixel format into a pixman format.
The VNC client pixel shifts are relative to the associated endianness.
The pixman formats are always relative to the host native endianness.
The qemu_pixman_get_format() method does not take into account the
VNC client endianness, and is thus returning a pixman format that is
only valid with the host endianness matches that of the VNC client.
This has been broken since pixman was introduced to the VNC server:
connecting from a LE client to a QEMU on a BE server, or the
reverse.
The bug was masked, however, because almost all VNC clients will
advertize support for the "tight" encoding and the QEMU VNC server
will prefer "tight" if advertized.
The tight_pack24 method is responsible for taking a set of pixels
which have already been converted into client endianness and then
repacking them into the TPIXEL format which the RFB spec defines
as
"TPIXEL is only 3 bytes long, where the first byte is the
red component, the second byte is the green component,
and the third byte is the blue component of the pixel
color value"
IOW, the TPIXEL format is fixed on the wire, regardless of what
the VNC client declare as its endianness.
Since the VNC pixel encoding code was failing to honour the endian
flag of the client, the tight_pack24 method was always operating
on data in native endianness. Its impl cancelled out the VNC pixel
encoding bug.
With the VNC pixel encoding code now fixed, the tight_pack24 method
needs to take into account that it is operating on data in client
endianness, not native endianness. It thus may need to invert the
pixel shifts.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 70097442853c389a765c9f6502d861d182b092ae) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
ui/vnc.c: replace big endian flag with byte order value
It will make it easier to do certain comparisons in future if we
store G_BIG_ENDIAN/G_LITTLE_ENDIAN directly, instead of a boolean
flag, as we can then compare directly to the G_BYTE_ORDER constant.
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:15 +0000 (15:33 +0800)]
ui/sdl: Consider scaling in mouse event handling
When using sdl display backend, if the window is scaled, incorrect mouse
positions will be reported since scaling is not properly handled. Fix it
by transforming the positions from window coordinate to guest buffer
coordinate.
Signed-off-by: Weifeng Liu <weifeng.liu@intel.com>
Message-ID: <20250511073337.876650-6-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 30aa105640b0a2a541744b6584d57c9a4b86debd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:14 +0000 (15:33 +0800)]
ui/gtk: Update scales in fixed-scale mode when rendering GL area
When gl=on, scale_x and scale_y were set to 1 on startup that didn't
reflect the real situation of the scan-out in free scale mode, resulting
in incorrect cursor coordinates to be sent when moving the mouse
pointer. Simply updating the scales before rendering the image fixes
this issue.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Message-ID: <20250511073337.876650-5-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 8fb072472c38cb1778c5b0bebf535a8b13533857) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:11 +0000 (15:33 +0800)]
ui/gtk: Document scale and coordinate handling
The existence of multiple scaling factors forces us to deal with various
coordinate systems and this would be confusing. It would be beneficial
to define the concepts clearly and use consistent representation for
variables in different coordinates.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Message-ID: <20250511073337.876650-2-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 9498e2f7e1a247557cfa0f830a86c398a23c6809) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jamin Lin [Thu, 22 May 2025 02:33:04 +0000 (10:33 +0800)]
hw/arm/aspeed_ast27x0: Fix RAM size detection failure on BE hosts
On big-endian hosts, the aspeed_ram_capacity_write() function previously passed
the address of a 64-bit "data" variable directly to address_space_write(),
assuming host and guest endianness matched.
However, the data is expected to be written in little-endian format to DRAM.
On big-endian hosts, this led to incorrect data being written into DRAM,
which caused the guest firmware to misdetect the DRAM size.
As a result, U-Boot fails to boot and hangs.
- Replaces the "address_space_write()" call with "address_space_stl_le()",
which performs an explicit 32-bit little-endian write.
- Updating the MemoryRegionOps to restrict access to exactly 4 bytes
using .valid.{min,max}_access_size = 4 and .impl.min_access_size = 4.
Jamin Lin [Thu, 15 May 2025 08:09:35 +0000 (16:09 +0800)]
hw/misc/aspeed_hace: Ensure HASH_IRQ is always set to prevent firmware hang
Currently, if the program encounters an unsupported algorithm, it does not set
the HASH_IRQ bit in the status register and send an interrupt to indicate
command completion. As a result, the FW gets stuck waiting for a completion
signal from the HACE module.
Additionally, in do_hash_operation, if an error occurs within the conditional
statement, the HASH_IRQ bit is not set in the status register. This causes the
firmware to continuously send HASH commands, as it is unaware that the HACE
model has completed processing the command.
To fix this, the HASH_IRQ bit in the status register must always be set to
ensure that the firmware receives an interrupt from the HACE module, preventing
it from getting stuck or repeatedly sending HASH commands.
Thomas Huth [Fri, 25 Apr 2025 12:07:10 +0000 (14:07 +0200)]
Drop support for Python 3.8
Python 3.8 went "end of life" in October 2024 and Fedora 42 dropped
this version already, so the "python" CI job is currently failing.
Thus it's time to drop support for this Python version in QEMU, too.
While we're at it, also look for "python3.13" in the configure script.
Message-ID: <20250425120710.879518-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit d64db833d6e3cbe9ea5f36342480f920f3675cea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Helge Deller [Sat, 17 May 2025 11:27:48 +0000 (13:27 +0200)]
target/hppa: Fix FPE exceptions
Implement FP exception register #1 (lower 32-bits of 64-bit fr[0]).
A proper implementation is necessary to allow the Linux kernel in
system mode and the qemu linux-user to send proper si_code values
on SIGFPE signal.
Always set the T-bit on taken exception, and merge over- and underflow
in system mode to just set overflow bit to mimic the behaviour I tested
on a physical machine.
The test program below can be used to verify correct behaviour. Note
that behaviour on SIGFPE may vary on different platforms. The program
should always detect the correct signal, but it may or may not be able
to sucessfully continue afterwards.
Helge Deller [Sat, 17 May 2025 11:20:17 +0000 (13:20 +0200)]
linux-user/hppa: Send proper si_code on SIGFPE exception
Improve the linux-user emulation to send the correct si_code depending
on overflow (TARGET_FPE_FLTOVF), underflow (TARGET_FPE_FLTUND), ...
Note that the hardware stores the relevant flags in FP exception
register #1, which is actually the lower 32-bits of the 64-bit fr[0]
register in qemu.
Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit b4b49cf39dba5f993ad925f204cb820aacfc8e45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
projects / thirdparty / qemu.git / log
