Problem
-------
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 06b636a1e2 ("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 0caed25cd1 ("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 06b636a1e2
("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: 06b636a1e2 ("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>
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>
Commit 3688fec892 ("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>
Commit b44135daa3 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: b44135daa3 ("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>
In the PMUv3, a new AArch32 64-bit (MCRR/MRRC) accessor for the
PMCCNTR was added. In QEMU we forgot to implement this, so only
provide the 32-bit accessor. Since we have a 64-bit PMCCNTR
sysreg for AArch64, adding the 64-bit AArch32 version is easy.
We add the PMCCNTR to the v8_cp_reginfo because PMUv3 was added
in the ARMv8 architecture. This is consistent with how we
handle the existing PMCCNTR support, where we always implement
it for all v7 CPUs. This is arguably something we should
clean up so it is gated on ARM_FEATURE_PMU and/or an ID
register check for the relevant PMU version, but we should
do that as its own tidyup rather than being inconsistent between
this PMCCNTR accessor and the others.
Since the register name is the same as the 32-bit PMCCNTR, we set
ARM_CP_NO_GDB on the 32-bit one to avoid generating an invalid GDB XML.
See https://developer.arm.com/documentation/ddi0601/2024-06/AArch32-Registers/PMCCNTR--Performance-Monitors-Cycle-Count-Register?lang=en
Note for potential backporting:
* this code in cpregs-pmu.c will be in helper.c on stable
branches that don't have commit ae2086426d
Cc: qemu-stable@nongnu.org
Signed-off-by: Alex Richardson <alexrichardson@google.com>
Message-id: 20250725170136.145116-1-alexrichardson@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
QEMU start failed when smp cpu < smp maxcpus , because qemu send a NULL
cpu to KVM, this patch adds a check for kvm_ipi_access_regs() to fix it.
run with '-smp 1,maxcpus=4,sockets=4,cores=1,threads=1'
we got:
Unexpected error in kvm_device_access() at ../accel/kvm/kvm-all.c:3477:
qemu-system-loongarch64: KVM_SET_DEVICE_ATTR failed: Group 1073741825 attr 0x0000000000010000: Invalid argument
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20250725081213.3867592-1-gaosong@loongson.cn>
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.
void main()
{
void *addr, *addr1;
int val;
addr = malloc(100);
*(int *)addr = 1;
addr1 = 0xffff000000000000ULL + addr;
val = *(int *)addr1;
printf("val %d \n", val);
}
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>
* Fix pmp range wraparound on zero
* Update FADT and MADT versions in ACPI tables
* Fix target register read when source is inactive
* Add riscv_hwprobe entry to linux-user strace list
* Do not call GETPC() in check_ret_from_m_mode()
* Revert "Generate strided vector loads/stores with tcg nodes."
* Fix exception type when VU accesses supervisor CSRs
* Restrict mideleg/medeleg/medelegh access to S-mode harts
* Restrict midelegh access to S-mode harts
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmiJbsUACgkQr3yVEwxT
gBPXCxAAhgcGh/mbdk/DZM4Gx9WqbfjU/1jZR9FCld9im3GLtJfq7IdEcsUZzpNb
E4sp49lr99qoogKhh3exYhBl0/t0WBoT5mtHNPLFRD3LX2gw6EFQWnD8FN1D//sO
QvyulomYbmI/Ywf5n5SszF4BpOKh7nyUEZBp4PU6vLT5btsZheSoTyCypH4a7KAy
GMFNO+O1k6NEwkUqqiIb9Pg8NOp/R3TlNWOjS8fwqyPSU/F8/pzehJQu4WOMAyM8
eGvqCZiwTg5CcLZfhQZ8dmqJ2qqI44FEzPjyq/Woq5hDmGDMl1iYhgjX5Ozy0X5j
m4Q+ZH0KIr18EkUD9z4fJbcQAMIm/2b90TShYon6+JYXX8DI8gUCvtg2vgsPAlnS
M6vgNT25qY8QZa/FbUGcP2+96AlaqX11jUou+TMuJMSr036gTP7gXux5hqYDrd0B
4WL1XPcfNZshK5+LAQ+2uwQ9JcKlEaw/mkZHvHgYN7a03UynjCn0oFZtTYvaB4Qx
Du8Rm9VPlLp3e25VmOiObYyq2Cf6sQXlWomKLJbvfCj217ZXvjOwEjj8hBcg3zJ/
6ix/wmDic+YtwmYE7EaGZaExpV5ZjZog61jzMziilZrCJarAoguq0P9tThXGtViX
TqQcn1V391EfVZYbS3JBO08xmkkX2k7Ia//Th35nByLt7zzrRbs=
=pKhf
-----END PGP SIGNATURE-----
Merge tag 'pull-riscv-to-apply-20250730-2' of https://github.com/alistair23/qemu into staging
Third RISC-V PR for 10.1
* Fix pmp range wraparound on zero
* Update FADT and MADT versions in ACPI tables
* Fix target register read when source is inactive
* Add riscv_hwprobe entry to linux-user strace list
* Do not call GETPC() in check_ret_from_m_mode()
* Revert "Generate strided vector loads/stores with tcg nodes."
* Fix exception type when VU accesses supervisor CSRs
* Restrict mideleg/medeleg/medelegh access to S-mode harts
* Restrict midelegh access to S-mode harts
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmiJbsUACgkQr3yVEwxT
# gBPXCxAAhgcGh/mbdk/DZM4Gx9WqbfjU/1jZR9FCld9im3GLtJfq7IdEcsUZzpNb
# E4sp49lr99qoogKhh3exYhBl0/t0WBoT5mtHNPLFRD3LX2gw6EFQWnD8FN1D//sO
# QvyulomYbmI/Ywf5n5SszF4BpOKh7nyUEZBp4PU6vLT5btsZheSoTyCypH4a7KAy
# GMFNO+O1k6NEwkUqqiIb9Pg8NOp/R3TlNWOjS8fwqyPSU/F8/pzehJQu4WOMAyM8
# eGvqCZiwTg5CcLZfhQZ8dmqJ2qqI44FEzPjyq/Woq5hDmGDMl1iYhgjX5Ozy0X5j
# m4Q+ZH0KIr18EkUD9z4fJbcQAMIm/2b90TShYon6+JYXX8DI8gUCvtg2vgsPAlnS
# M6vgNT25qY8QZa/FbUGcP2+96AlaqX11jUou+TMuJMSr036gTP7gXux5hqYDrd0B
# 4WL1XPcfNZshK5+LAQ+2uwQ9JcKlEaw/mkZHvHgYN7a03UynjCn0oFZtTYvaB4Qx
# Du8Rm9VPlLp3e25VmOiObYyq2Cf6sQXlWomKLJbvfCj217ZXvjOwEjj8hBcg3zJ/
# 6ix/wmDic+YtwmYE7EaGZaExpV5ZjZog61jzMziilZrCJarAoguq0P9tThXGtViX
# TqQcn1V391EfVZYbS3JBO08xmkkX2k7Ia//Th35nByLt7zzrRbs=
# =pKhf
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 29 Jul 2025 21:00:53 EDT
# gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013
* tag 'pull-riscv-to-apply-20250730-2' of https://github.com/alistair23/qemu:
target/riscv: Restrict midelegh access to S-mode harts
target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts
target/riscv: Fix exception type when VU accesses supervisor CSRs
riscv: Revert "Generate strided vector loads/stores with tcg nodes."
target/riscv: do not call GETPC() in check_ret_from_m_mode()
linux-user/strace.list: add riscv_hwprobe entry
intc/riscv_aplic: Fix target register read when source is inactive
tests/data/acpi/riscv64: Update expected FADT and MADT
hw/riscv/virt-acpi-build.c: Update FADT and MADT versions
bios-tables-test-allowed-diff.h: Allow RISC-V FADT and MADT changes
target/riscv: Fix pmp range wraparound on zero
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
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>
When supervisor CSRs are accessed from VU-mode, a virtual instruction
exception should be raised instead of an illegal instruction.
Fixes: c1fbcecb3a (target/riscv: Fix csr number based privilege checking)
Signed-off-by: Xu Lu <luxu.kernel@bytedance.com>
Reviewed-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Message-ID: <20250708060720.7030-1-luxu.kernel@bytedance.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This reverts commit 28c12c1f2f.
As reported in [1] this commit is breaking Linux vector code, and
although a simpler reproducer was provided, the fix itself isn't trivial
due to the amount and the nature of the changes. And we really do not
want to keep Linux broken while we work on it.
The revert will fix Linux and will give us time to do a proper fix.
[1] https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02525.html
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Tested-by: Eric Biggers <ebiggers@kernel.org>
Message-ID: <20250710100525.372985-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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.
[1] https://gitlab.com/qemu-project/qemu/-/issues/3020
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Fixes: 3157a553ec ("target/riscv: Add Smrnmi mnret instruction")
Closes: https://gitlab.com/qemu-project/qemu/-/issues/3020
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250714133739.1248296-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
We're missing a strace entry for riscv_hwprobe, and using -strace will
report it as "Unknown syscall 258".
After this patch we'll have:
$ ./build/qemu-riscv64 -strace test_mutex_riscv
110182 riscv_hwprobe(0x7f207efdc700,1,0,0,0,0) = 0
110182 brk(NULL) = 0x0000000000082000
(...)
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>
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>
RISC-V support is added only in ACPI 6.6. According to the ACPI 6.6
specification, the minor version of the Fixed ACPI Description Table
(FADT) should be 6, and the Multiple APIC Description Table (MADT)
should use revision 7. So, update the RISC-V FADT and MADT to reflect
correct versions.
Update the code comments to reflect ACPI 6.6 version details.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Message-ID: <20250724110350.452828-3-sunilvl@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
Message-ID: <20250724110350.452828-2-sunilvl@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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>
The test passed when it was added. However, the commit adding it
neglected to make Meson aware of it, so it never ran automatically.
The test stopped making sense when we changed headings markup, and
ceased to pass then. It should've been removed then. Do that now.
Fixes: 6c10778826 (docs/sphinx: remove special parsing for freeform sections)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250724091742.1950167-3-armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
The docs generated for qapi/accelerator.json shows text "=
Accelerators" instead of a heading. This is because the patch that
added the heading crossed with the commit that changed heading
markup (commit 6c10778826 "docs/sphinx: remove special parsing for
freeform sections"). Fix the markup.
Fixes: 18da42ee42 (qapi/accel: Move definitions related to accelerators in their own file)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250724091742.1950167-2-armbru@redhat.com>
We recently (merge commit 504632dcc6) enclosed command and type
names in `backquotes`, so they become links in generated HTML. Take
care of a few we missed.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250717115751.3832597-1-armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
"qemu/error-report.h" was previously implicitly included. This is no
longer the case following 012842c075.
However, the issue predates this change as `error-report.h` should have
been included when the `warn_report` call was introduced.
Fixes: fa140b9562 ("hw/sm501: allow compiling without PIXMAN")
Signed-off-by: Clément Chigot <chigot@adacore.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250728090518.963573-1-chigot@adacore.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Since commit 70ce076fa6, the actual rom source dirs
are subdirs of vbootrom/ submodule, not in top-level of it.
Fixes: 70ce076fa6 "roms: Update vbootrom to 1287b6e"
Fixes: 269b7effd9 ("pc-bios: Add NPCM8XX vBootrom")
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250727215511.807880-1-mjt@tls.msk.ru>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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 0d58c66068 [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.
[1] 0d58c66068
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3040
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250724161142.2803091-1-pierrick.bouvier@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In commit cfcacbab38 ("xen/passthrough: use gsi to map pirq when
dom0 is PVH") an `error_report` was added to this file, but the
corresponding include of `qemu/error-report.h` was missed. This
only becomes apparent when building against Xen 4.20+ with trace
backend log disabled.
Fixes: cfcacbab38 (xen/passthrough: use gsi to map pirq when dom0 is PVH)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250717220207.171040-1-awilliam@redhat.com>
[PMD: Improved commit description, added Fixes: tag]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The gem_init_register_masks function was called at init time but it
relies on the num-priority-queues property. Call it at realize time
instead.
Cc: qemu-stable@nongnu.org
Fixes: 4c70e32f05 ("net: cadence_gem: Define access permission for interrupt registers")
Signed-off-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Sai Pavan Boddu <sai.pavan.boddu@amd.com>
Message-ID: <20250716095432.81923-2-luc.michel@amd.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
"qemu/typedefs.h" is already included by "qemu/osdep.h".
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250708085859.7885-3-philmd@linaro.org>
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
Tested-by: Thaddeus Hogan <thaddeus@thogan.com>
Tested-by: Vadim Zeitlin <vadim@wxwidgets.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250221134856.478806-1-mjt@tls.msk.ru>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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: f249412c74 ("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>
In commit a59d06305f ("vfio/pci: Introduce x-pci-class-code option"),
pci_register_vga() has been moved ouside of vfio_populate_vga(). As a
result, IGD VGA ranges are no longer properly exposed to guest.
To fix this, call pci_register_vga() after vfio_populate_vga() legacy
mode. A wrapper function vfio_pci_config_register_vga() is introduced
to handle it.
Fixes: a59d06305f ("vfio/pci: Introduce x-pci-class-code option")
Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250723160906.44941-3-tomitamoeko@gmail.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Commit a59d06305f ("vfio/pci: Introduce x-pci-class-code option")
allows user to expose non-VGA IGD device as VGA controller to the
guest. However, legacy mode requires host VGA range access. Check
that GGC.IVD == 0 before enabling legacy mode to ensure IGD is a real
VGA device claiming host VGA ranges.
Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250723160906.44941-2-tomitamoeko@gmail.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Regions for sub-page BARs are normally mapped here, in response to the
guest writing to PCI config space:
vfio_pci_write_config()
pci_default_write_config()
pci_update_mappings()
memory_region_add_subregion()
vfio_sub_page_bar_update_mapping()
... vfio_dma_map()
However, after CPR, the guest does not reconfigure the device and the
code path above is not taken. To fix, in vfio_cpr_pci_post_load, call
vfio_sub_page_bar_update_mapping for each sub-page BAR with a valid
address.
Fixes: 7e9f214113 ("vfio/container: restore DMA vaddr")
Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Link: https://lore.kernel.org/qemu-devel/1752520890-223356-1-git-send-email-steven.sistare@oracle.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Recent changes broke build on 32-bit host. Since there is no 32-bit
support, restrict SEV to 64-bit.
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250716071554.377356-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Commit 350785d41d ("ramfb: Add property to control if load the
romfile") introduced the `use-legacy-x86-rom` property for the
`vfio-pci-nohotplug` device, allowing control over VGA BIOS ROM
loading. However, the property compatibility setting was incorrectly
applied to the `vfio-pci` device instead, which causes all `vfio-pci`
devices to fail to load. This change fixes the issue by ensuring the
property is set on the correct device.
Fixes: d5fcf0d960 ("hw/i386: Add the ramfb romfile compatibility")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Shaoqin Huang <shahuang@redhat.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250723062714.1245826-1-clg@redhat.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
- improve clarity of user-mode docs
- remove reference to TAP tarball
- add new hypervisor test for aarch64 EL2
- reduce combinatorial explosion of plugin tests
- make docker-all-test-cross more friendly to non-x86 hosts
- expose unittests to sysv.args for embedded help
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmiFUdoACgkQ+9DbCVqe
KkQn+Af/RpTh4XmIcqiLvXrygLWo8hSELS0gjIRZgAA8QyBmojZ+e13los3pzm2Z
WWlQhh4T0OHgMtZCPPrP+XUc/QDgV3Pt41C1O6SWRwqD4v/7oWNNZz+pFra7x160
CLBJfcVuRKdFzuR1NZldR8LJufmAMnPnBwE+cV9SpBlGe/lvcLPPvjF0eXQnW1yP
fWmNgf7VnLBPEQ3NQkliZ23Ku6p4yWDfJLfqgUAXe57Eom1PpDEaPlc+5UaYtAKs
ee6Gk5CqVFUhIj0v50qBn1giLyaqaXyGn9yWiwiNDL/qVV1v+DK7LNt5B0bTXCfd
X1KTwpJJdbzmcDftrAq+oacaeXryIA==
=Sxa/
-----END PGP SIGNATURE-----
Merge tag 'pull-10.1-rc1-maintainer-260725-1' of https://gitlab.com/stsquad/qemu into staging
documentation and test cleanups
- improve clarity of user-mode docs
- remove reference to TAP tarball
- add new hypervisor test for aarch64 EL2
- reduce combinatorial explosion of plugin tests
- make docker-all-test-cross more friendly to non-x86 hosts
- expose unittests to sysv.args for embedded help
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmiFUdoACgkQ+9DbCVqe
# KkQn+Af/RpTh4XmIcqiLvXrygLWo8hSELS0gjIRZgAA8QyBmojZ+e13los3pzm2Z
# WWlQhh4T0OHgMtZCPPrP+XUc/QDgV3Pt41C1O6SWRwqD4v/7oWNNZz+pFra7x160
# CLBJfcVuRKdFzuR1NZldR8LJufmAMnPnBwE+cV9SpBlGe/lvcLPPvjF0eXQnW1yP
# fWmNgf7VnLBPEQ3NQkliZ23Ku6p4yWDfJLfqgUAXe57Eom1PpDEaPlc+5UaYtAKs
# ee6Gk5CqVFUhIj0v50qBn1giLyaqaXyGn9yWiwiNDL/qVV1v+DK7LNt5B0bTXCfd
# X1KTwpJJdbzmcDftrAq+oacaeXryIA==
# =Sxa/
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 26 Jul 2025 18:08:26 EDT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.1-rc1-maintainer-260725-1' of https://gitlab.com/stsquad/qemu:
tests/functional: expose sys.argv to unittest.main
tests/docker: handle host-arch selection for all-test-cross
tests/docker: add --arch-only to qemu deps for all-test-cross
tests/tcg: reduce the number of plugin tests combinations
configure: expose PYTHON to test/tcg/config-host.mak
tests/tcg: don't include multiarch tests if not supported
tests/tcg: remove ADDITIONAL_PLUGINS_TESTS
tests/tcg: skip libsyscall.so on softmmu tests
tests/functional: add hypervisor test for aarch64
docs/user: expand section on threading
docs/user: slightly reword section on system calls
docs/user: clean up headings
docs/system: reword the TAP notes to remove tarball ref
docs/user: clarify user-mode expects the same OS
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
linux-user/aarch64: Support TPIDR2_MAGIC signal frame record
linux-user/aarch64: Support ZT_MAGIC signal frame record
-----BEGIN PGP SIGNATURE-----
iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmiF1rwdHHJpY2hhcmQu
aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV935wf7BXGiD3m1MfLofofa
w5/j4AjKw2sNAS3gVhmu9+BKKdctvNDxpNv4vx79j58iTuPCpi6roQ3vOEJWR0Vb
0UdJc/vNvFrXWLTW+W5nncKjCYZeTgSbWy3xwfnR3u4fk8YkUbGjVZ9TAgXl3dA1
NGagGqrlCqJpDYxbRWRIhXE+dF5zfNqU4gDTLG+C8xCN/gT7TkDIOU9sNb2uu1PC
eI/SplpZYBDpdzpjko35peyq0tqUJrYT6P1MMjQckGpnKTSMynQmYvKVkloALRpW
Zx3mBu9cWl77D57Fw4AijEiuUGhN0kZB12gH9VRp29rlTRr/MR4Y0seOU6XDc341
eGe5pg==
=avvX
-----END PGP SIGNATURE-----
Merge tag 'pull-lu-20250726' of https://gitlab.com/rth7680/qemu into staging
linux-user/aarch64: Clear TPIDR2_EL0 when delivering signals
linux-user/aarch64: Support TPIDR2_MAGIC signal frame record
linux-user/aarch64: Support ZT_MAGIC signal frame record
# -----BEGIN PGP SIGNATURE-----
#
# iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmiF1rwdHHJpY2hhcmQu
# aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV935wf7BXGiD3m1MfLofofa
# w5/j4AjKw2sNAS3gVhmu9+BKKdctvNDxpNv4vx79j58iTuPCpi6roQ3vOEJWR0Vb
# 0UdJc/vNvFrXWLTW+W5nncKjCYZeTgSbWy3xwfnR3u4fk8YkUbGjVZ9TAgXl3dA1
# NGagGqrlCqJpDYxbRWRIhXE+dF5zfNqU4gDTLG+C8xCN/gT7TkDIOU9sNb2uu1PC
# eI/SplpZYBDpdzpjko35peyq0tqUJrYT6P1MMjQckGpnKTSMynQmYvKVkloALRpW
# Zx3mBu9cWl77D57Fw4AijEiuUGhN0kZB12gH9VRp29rlTRr/MR4Y0seOU6XDc341
# eGe5pg==
# =avvX
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 27 Jul 2025 03:35:24 EDT
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* tag 'pull-lu-20250726' of https://gitlab.com/rth7680/qemu:
linux-user/aarch64: Support ZT_MAGIC signal frame record
linux-user/aarch64: Support TPIDR2_MAGIC signal frame record
linux-user/aarch64: Clear TPIDR2_EL0 when delivering signals
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Enclose command and type names in `backquotes`, so they become links
in generated HTML.
We did this for qapi/ in merge commit 504632dcc6.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250717115246.3830007-5-armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
"Returns: <description>" is rendered like
Return: <Type> – <description>
Mentioning the type in the description again is commonly redundant.
There is just one such description. Rephrase it not to mention the
type.
We did this for qapi/ in commit f7296f8de5 (qapi: rephrase return
docs to avoid type name).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250717115246.3830007-4-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
The QAPI doc generator recently started to auto-generate return
documentation when there is no "Returns:" section (commit 636c96cd77
"qapi: Fix undocumented return values by generating something").
Remove "Returns:" sections where the auto-generated text is obviously
no worse. For instance, guest-info's documentation changes from
Return:
GuestAgentInfo -- GuestAgentInfo
to
Return:
GuestAgentInfo
The auto-generated returns all are in the exact same spot.
We did this for qapi/ in commit 0462da9d6b (qapi: remove trivial
"Returns:" sections).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250717115246.3830007-3-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
