Remove tcg/arm.
Remove instances of __arm__, except from tests and imported headers.
Remove arm from supported_cpus.
Remove linux-user/include/host/arm.
Remove common-user/host/arm.
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Merge tag 'accel-20260116' of https://github.com/philmd/qemu into staging
Accelerators patches queue
- Enable 64bit WebAssembly guests (TCI)
- Fix migration on HVF
- Remove a signal race with WFI on HVF (Aarch64)
- Correct HVF guest timer frequency (Aarch64)
- Fix NVMM build (x86)
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmlqHhcACgkQ4+MsLN6t
# wN7NEA//cZvw4AdTKgUxenEQL2r+Y8KVT+Wm+F7WqznTm9dqGgb+YHgmDoPA9b6y
# qxenzIwVA1R2ZkgAs7m99z9k9YcZLXHdoKelWYqxoWZd1DFVQJ7by5iRoQbvdtRJ
# LSxQXkdcXCGBIWQ080k0WJP5e7Sw/1+LdSm3jn2naRTD1JF3jn4LwUZMFQSwuhH0
# 0uXFrb207AlFz4itNnZXIjcvugMi6hIKNhHX8ol0JLSlfkS0lVR4y1X21J11ipg3
# VYucsUfA9fzfqcTDkPxGuEAV5mivaP1wy8kHRh5p8vgq7dbLivdIpjYIZynzb1LF
# 10WaeJaYHHYeWqLSKcZPUd66eKc2ZOeGn+zcE8oM8Zsm2NQUJ+rIkWw7/O978PfS
# RsXmIYTkM8gXfx7gUtW95/JmX5FH4xsvrwRjv1FdOPwYNe3kMtc1xslq9dkqsXMG
# P79n+NVXRr62ph93lSjLdLgqFW6eEXo0nVO4maD+9pBolK9S8TIrzLxRwXyHY/lx
# FD9nRHP/U1QjrrwpCcFT3PmTfJ/CsMlP0biUG9+uf6XKkxlOIyNoMSDdTC5xjUTx
# iCC71XluRIBKAIpwIN9QHtTTrKvm2wMFlTHpQxMD/kldc+0whHBtfU/24vemCCMQ
# dpnJxr0lVng942YHhT/n2Y6CZbzURF022I89p7EJ6d/1Els0j/c=
# =khzj
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 16 Jan 2026 10:16:39 PM AEDT
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'accel-20260116' of https://github.com/philmd/qemu: (30 commits)
tests/functional: Require TCG to run reverse debugging tests
target/i386/nvmm: Include missing ramlist.h header
accel/nvmm: Fix 'cpu' typo in nvmm_init_vcpu()
hmp-commands-info.hx: Move definition of "info accel"
target/arm: Only allow disabling NEON when using TCG
target/arm/hvf: Really set Generic Timer counter frequency
target/arm: Create GTimers *after* features finalized / accel realized
accel/hvf: Add hvf_arch_cpu_realize() stubs
accel: Introduce AccelOpsClass::cpu_target_realize() hook
accel/hvf: Have PSCI CPU_SUSPEND halt the vCPU
accel/hvf: Implement WFI without using pselect()
accel/hvf: Skip WFI if CPU has work to do
target/arm/hvf: Implement dirty page tracking
accel/hvf: Remove mac_slots
accel/hvf: Drop hvf_slot and hvf_find_overlap_slot
accel/hvf: Simplify hvf_set_phys_mem
accel/hvf: Move hvf_log_sync to hvf_log_clear
accel/hvf: Simplify hvf_log_*
target/i386/hvf: Use address_space_translate in ept_emulation_fault
target/i386/hvf: Use hvf_unprotect_dirty_range
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tests/functional: Require TCG to run reverse debugging tests
Record/replay is specific to TCG. Require it to avoid failure
when using a HVF-only build on Darwin:
qemu-system-aarch64: -icount shift=7,rr=record,rrfile=/scratch/replay.bin,rrsnapshot=init: cannot configure icount, TCG support not available
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20260115161029.24116-1-philmd@linaro.org>
target/i386/nvmm/nvmm-all.c: In function 'nvmm_init_vcpu':
target/i386/nvmm/nvmm-all.c:988:9: error: 'AccelCPUState' has no member named 'vcpu_dirty'
988 | qcpu->vcpu_dirty = true;
| ^~
Cc: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Fixes: 2098164a6be ("accel/nvmm: Replace @dirty field by generic CPUState::vcpu_dirty field") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Tested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260113203924.81560-1-philmd@linaro.org>
hmp-commands-info.hx: Move definition of "info accel"
Commit c10eb740108 (accel/system: Add 'info accel' on human monitor)
inserted "info accel" in the middle of "info sync-profile". Move it
behind "info sync-profile".
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260116005050.376616-2-dave@treblig.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
target/arm: Only allow disabling NEON when using TCG
Only allow disabling NEON when using TCG.
This avoids confusing user experience:
$ qemu-system-aarch64 -M virt -accel hvf \
-cpu host,neon=off,vfp=off,vfp-d32=off
qemu-system-aarch64: AArch64 CPUs must have both VFP and Neon or neither
$ qemu-system-aarch64 -M virt -accel hvf \
-cpu host,neon=off,vfp=off,vfp-d32=off
qemu-system-aarch64: ARM CPUs must have both VFP-D32 and Neon or neither
$ qemu-system-aarch64 -M virt -accel hvf \
-cpu host,neon=off,vfp=off,vfp-d32=off
qemu-system-aarch64: can't apply global host-arm-cpu.vfp-d32=off: Property 'host-arm-cpu.vfp-d32' not found
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260112103034.65310-20-philmd@linaro.org>
All of the complicated parts of updating the address space
are handled by address_space_update_topology_pass.
Do not create or use hvf_slot structures.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260112103034.65310-9-philmd@linaro.org>
Right idea, wrong hook. log_sync is called before using
dirty bit data (which for hvf is already up-to-date),
whereas log_clear is called before cleaning the range.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20260112103034.65310-8-philmd@linaro.org>
target/i386/hvf: Use address_space_translate in ept_emulation_fault
The hvf_slot structure is a poor replacement for properly
looking up a memory region in the address space.
Use memory_region_get_dirty_log_mask instead of HVF_SLOT_LOG.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20251103101034.59039-6-philmd@linaro.org>
Kohei Tokunaga [Mon, 4 Aug 2025 12:57:17 +0000 (21:57 +0900)]
gitlab-ci: Add build tests for wasm64
The wasm builds are tested for 3 targets: wasm32, wasm64(-sMEMORY64=1) and
wasm64(-sMEMORY64=2). The CI builds the containers using the same Dockerfile
(emsdk-wasm-cross.docker) with different build args.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <ee30d4956a485fd46b4735028486d3fb7b22fe60.1768308374.git.ktokunaga.mail@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Kohei Tokunaga [Mon, 4 Aug 2025 12:57:16 +0000 (21:57 +0900)]
dockerfiles: Add support for wasm64 to the wasm Dockerfile
This commit fixes Dockerfile of the wasm build to support both of wasm32 and
wasm64 build. Dockerfile takes the following build argument and use it for
building dependencies.
- TARGET_CPU: target wasm arch (wasm32 or wasm64)
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <3f21342f50e0412a32143fe21ecc0d8db95b3f37.1768308374.git.ktokunaga.mail@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Kohei Tokunaga [Mon, 4 Aug 2025 12:57:15 +0000 (21:57 +0900)]
configure: Enable to propagate -sMEMORY64 flag to Emscripten
Currently there are some engines that don't support wasm64 (e.g. unsupported
on Safari[1]). To mitigate this issue, the configure script allows the user
to use Emscripten's compatibility feature, "-sMEMORY64=2" flag[2].
Emscripten's "-sMEMORY64=2" flag still enables 64bit pointers in C code. But
this flag lowers the output binary into wasm32, with limiting the maximum
memory size to 4GB. So QEMU can run on wasm32 engines.
Kohei Tokunaga [Mon, 4 Aug 2025 12:57:14 +0000 (21:57 +0900)]
meson: Add wasm64 support to the --cpu flag
wasm64 target enables 64bit pointers using Emscripten's -sMEMORY64=1
flag[1]. This enables QEMU to run 64bit guests.
Although the configure script uses "uname -m" as the fallback value when
"cpu" is empty, this can't be used for Emscripten which targets to Wasm.
So, in wasm build, this commit fixes configure to require --cpu flag to be
explicitly specified by the user.
tests/qtest/migration: Make 'has_dirty_ring' generic
Keep accelerator knowledge limited within MigrationTestEnv,
expose a generic %has_dirty_ring value, only checking for
KVM when initializing it in migration_get_env().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250128135429.8500-3-philmd@linaro.org>
Merge tag 'pull-target-arm-20260115' of https://gitlab.com/pm215/qemu into staging
target-arm queue:
* hw/arm/raspi: remove duplicate include
* target/arm: Enable FEAT_ASID2 emulation
* hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
* hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
* target/arm/ptw: make granule_protection_check usable without a cpu
* hw/arm/omap: Remove omap_badwidth_* functions
* hw/arm/smmu: add memory regions as property for an SMMU instance
* docs/system/generic-loader: clarify
* tests/functional: migrate aspeed_rainier image
* target/arm: Correctly handle HCR.TID1 and TID3 traps on v7A CPUs
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmlpN5EZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3j/QD/9G1AV5Sd59zoO//cS6m7OO
# dB0/1MaX7ChTK4zHaQwA2TammwKTxUDV1nj8LJBd4/d1SV1SC3OrYl88bQdjKhLD
# +o4z9snfV+TmVm6WlmKvDkOhV0UdhrA31exvXFOXytmVSq6BxvHv/yy2j4eo8KVu
# UtWf8A2RHnfR1QNIvBGtDQ7NWhd9XHV8mKtGMIiTTQtQ72/9MLig9Kbv97yavbRT
# ZY8AdvDZJrR8P7euRc//qmGuWb6ix2GiFRWQ0FXQu/qU63MR+Css12nzkXFFGeU2
# KEtZ2PTwd8i/NRYtJmqVw3ZsQHAqXplGle/VzK7orTLWKHbjiLOc9FdnSVplkBNM
# AWhQGVqrwXYHnEI34RiTQuxzhNepPwOgS6/0gXw2mHzHQ5g6ndZnfJuPTw/70ZNY
# Yd0nAU1ajvgW/1/i9zVs4aQ5wy/SFRd+OoHqujVIcKWB9iPWvNZUGgrnySQO8lq+
# 6GOMZauK+8kU4WJO/wHCW9ktIUPWjwYmmTLwElTj/VUEjShy2t8mETZEvzJl+eVl
# WZpzfJEvbraJiCe+e2QRcRA0goTlBdNneUQ31ePoVOpXS6UXIXuqd3Qisli9y4sB
# 9NrJseIQ7RclIYfpHxkrlejXGOFlwtxaDoxSupn7IblKCCFFf6TS3LwiJRXpcf2k
# kpMq6Mcnt/HCrpvmN5gNUA==
# =yMo2
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 16 Jan 2026 05:53:05 AM AEDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260115' of https://gitlab.com/pm215/qemu: (25 commits)
target/arm: Rename access_aa64_tid5() to access_tid5()
target/arm: Correctly trap HCR.TID1 registers in v7A
target/arm: Correctly honour HCR.TID3 for v7A cores
target/arm: Don't specify ID_PFR1 accessfn twice
tests/functional: migrate aspeed_rainier image
docs/system/generic-loader: move TODO to source code
docs/system/generic-loader: Don't mention QemuOpts implementation detail
docs/system/generic-loader: Clarify behaviour of cpu-num
hw/arm/smmu: add memory regions as property for an SMMU instance
hw/arm/omap1: Remove omap_badwidth_* implementations
hw/arm/omap1: Remove omap_badwidth_write* calls
hw/arm/omap1: Remove omap_badwidth_read* calls
hw/dma/omap_dma: Remove omap_badwidth_* calls
hw/gpio/omap_gpio: Remove omap_badwidth_* calls
hw/i2c/omap_i2c: Remove omap_badwidth_* calls
hw/sd/omap_mmc: Remove omap_badwidth_* calls
target/arm/ptw: make granule_protection_check usable without a cpu
target/arm: Move ARMSecuritySpace to a common header
hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Merge tag 'pull-loongarch-20260115' of https://github.com/bibo-mao/qemu into staging
loongarch queue
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCaWiLIAAKCRAfewwSUazn
# 0cGHAQCVjRn2wPtniAIS6HQ/edTPXQt8Nr83Bv6SHkcOskbexwEA/OmUd4MiftSV
# GJFfJ66Z3i9TCRZJdLqsUZBk9p9W9AQ=
# =Aiem
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 15 Jan 2026 05:37:20 PM AEDT
# gpg: using EDDSA key 0D8642A3A2659F80B0B3D1A41F7B0C1251ACE7D1
# gpg: Good signature from "bibo mao <maobibo@loongson.cn>" [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: 7044 3A00 19C0 E97A 31C7 13C4 8E86 8FB7 A176 9D4C
# Subkey fingerprint: 0D86 42A3 A265 9F80 B0B3 D1A4 1F7B 0C12 51AC E7D1
* tag 'pull-loongarch-20260115' of https://github.com/bibo-mao/qemu:
hw/loongarch/virt: Don't abort on access to unimplemented IOCSR
target/loongarch: Fix exception ADEF/ADEM missing to update CSR_BADV
target/loongarch: Fix exception BCE missing to update CSR_BADV
target/loongach: Fix some exceptions failure in updating CSR_BADV
hw/loongarch/virt: Fix irq allocation failure with pci device from fdt
hw/loongarch/virt: Modify the interrupt trigger type in fdt table
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Wed, 31 Dec 2025 17:08:58 +0000 (17:08 +0000)]
target/arm: Rename access_aa64_tid5() to access_tid5()
There is no equivalent access_aa32_tid5() (HCR_EL2.TID5 only exists
starting from v8); rename access_aa64_tid5() to access_tid5() to line
up with the naming we now have for the TID1 and TID3 check functions.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-5-peter.maydell@linaro.org
Peter Maydell [Wed, 31 Dec 2025 17:08:57 +0000 (17:08 +0000)]
target/arm: Correctly trap HCR.TID1 registers in v7A
In v7A HCR.TID1 is defined to trap for TCMTR, TLBTR, REVIDR and AIDR.
We incorrectly use an accessfn for REVIDR and AIDR that only traps on
v8A cores. Fix this by collapsing access_aa64_tid1() and
access_aa32_tid1() together and never doing a check for v8 vs v7.
The accessfn is also used for SMIDR_EL1, which is fine as this
register is AArch64 only.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-4-peter.maydell@linaro.org
Peter Maydell [Wed, 31 Dec 2025 17:08:56 +0000 (17:08 +0000)]
target/arm: Correctly honour HCR.TID3 for v7A cores
The HCR.TID3 bit defines that we should trap to the hypervisor for
reads to a collection of ID registers. Different architecture versions
have defined this differently:
* v7A has a set of ID regs that definitely must trap:
- ID_PFR{0,1}, ID_DFR0, ID_AFR0, ID_MMFR{0,1,2,3},
ID_ISAR{0,1,2,3,4,5}, MVFR{0,1}
and somewhat vaguely says that "there is no requirement"
to trap for registers that are reserved in the ID reg space
(i.e. which RAZ and might be used for new ID regs in future)
* v8A adds to this list:
- ID_PFR2 and MVFR2 must trap
- ID_MMFR4, ID_MMFR5, ID_ISAR6, ID_DFR1 and reserved registers
in the ID reg space must trap if FEAT_FGT is implemented,
and it is IMPDEF if they trap if FEAT_FGT is not implemented
In QEMU we seem to have attempted to implement this distinction
(taking the "we do trap" IMPDEF choice if no FEAT_FGT), with
access_aa64_tid3() always trapping on TID3 and access_aa32_tid3()
trapping only if ARM_FEATURE_V8 is set. However, we didn't apply
these to the right set of registers: we use access_aa32_tid3() on all
the 32-bit ID registers *except* ID_PFR2, ID_DFR1, ID_MMFR5 and the
RES0 space, which means that for a v7 CPU we don't trap on a lot of
registers that we should trap on, and we do trap on various things
that the v7A Arm ARM says there is "no requirement" to trap on.
Straighten this out by naming the access functions more clearly for
their purpose, and documenting this: access_v7_tid3() is only for the
fixed set of ID registers that v7A traps on HCR.TID3, and
access_tid3() is for any others, including the reserved encoding
spaces and any new registers we add in future.
AArch32 MVFR2 access is handled differently, in check_hcr_el2_trap;
there we already do not trap on TID3 on v7A cores (where MVFR2
doesn't exist), because we in the code-generation function we UNDEF
if ARM_FEATURE_V8 is not set, without generating code to call
check_hcr_el2_trap.
This bug was causing a problem for Xen which (after a recent change
to Xen) expects to be able to trap ID_PFR0 on a Cortex-A15.
The result of these changes is that our v8A behaviour remains
the same, and on v7A we now trap the registers the Arm ARM definitely
requires us to trap, and don't trap the reserved space that "there is
no requirement" to trap.
Cc: qemu-stable@nongnu.org Fixes: 6a4ef4e5d1084c ("target/arm: Honor HCR_EL2.TID3 trapping requirements") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-3-peter.maydell@linaro.org
Peter Maydell [Wed, 31 Dec 2025 17:08:55 +0000 (17:08 +0000)]
target/arm: Don't specify ID_PFR1 accessfn twice
In the definition of ID_PFR1 we have an ifdef block; we specify the
accessfn once in the common part of the ifdef and once in the
not-user-only part, which is redundant but harmless.
The accessfn will always return success in user-only mode (because
we won't trap to EL2), so specify it only in the not-user-only
half of the ifdef, as was probably the intention.
This is only cc'd to stable to avoid a textual conflict with
the following patch, which is a bug fix.
Cc: qemu-stable@nongnu.org Fixes: 0f150c8499e970bd ("target/arm: Constify ID_PFR1 on user emulation") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251231170858.254594-2-peter.maydell@linaro.org
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
docs/system/generic-loader: move TODO to source code
Currently we have a "Restrictions and ToDos" section at the bottom of
the document which notes that there's no way to specify a CPU to load
a file through that doesn't also set that CPU's PC. This is written
as a developer-facing note. Move this to a TODO comment in the
source code, and provide a shorter user-facing statement of the
current restriction under the specific sub-option that it applies to.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
We currently say "All values are parsed using the standard QemuOpts
parsing". This doesn't tell the user anything useful because we
don't mention QemuOpts anywhere else in the docs. What we're really
trying to tell the user is what we mention afterwards: that the
values are decimal, and you need an 0x prefix for hex. How we
achieve it is an implementation detail the user doesn't need to know.
Drop the explicit mention of QemuOpts; this in passing removes a typo
"QemuOps" that we made in one place. Put the informative note
more closely associated with the <addr> suboption which is the
one that users might most reasonably assume to default to hex.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
docs/system/generic-loader: Clarify behaviour of cpu-num
The cpu-num suboption to the generic loader has two effects when
it is used with -device loader,file=<file>:
* it specifies which CPU to load the data through
* it specifies which CPU gets its PC set to the file's entry point
Our documentation is not very clear about what happens if you don't
pass this suboption. The default is that we pick the first CPU to
load the data, but we don't set the PC for any CPU, so the "If not
specified, the default is CPU 0" is confusing: it applies for loading
but not for the PC setting.
Clarify the text to make it clearer that the option has two effects
and the default behaviour is different for the two effects.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/arm/omap1: Remove omap_badwidth_write* calls
Complete the conversion started in the previous commit by
changing all the omap_badwidth_write* calls to open-coded
log-and-ignore behaviour.
We can delete a FIXME comment about an infinite loop, because that
only looped infinitely back before 2011 when the device was still
using absolute physical addresses. Now that we are simply logging
the error we can clearly see that there's no loop.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/arm/omap1: Remove omap_badwidth_read* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of the omap_badwidth_read* functions in omap1.c with
an open-coded call to qemu_log_mask() and RAZ/WI behaviour.
We do just the reads here because there are a lot of callsites in
omap1.c; the writes will be done in the next commit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/dma/omap_dma: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_dma.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/gpio/omap_gpio: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_gpio.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/i2c/omap_i2c: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_i2c.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Peter Maydell [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
hw/sd/omap_mmc: Remove omap_badwidth_* calls
The omap_badwidth_read* and omap_badwidth_write* functions are
used by various OMAP devices when the guest makes an access
to registers with an invalid width; they do two things:
- log a GUEST_ERROR for the access
- call cpu_physical_memory_read() or cpu_physical_memory_write()
with the offset they are passed in
The first of these produces an unhelpful log message because the
function name that is printed is that of the omap-badwidth_*
function, not that of the read or write function of the device that
called it; this means you can't tell what device is involved.
The second is wrong because the offset is an offset into the device
but we use it as an absolute physical address, so we will access
whatever is at low memory. That happens to be the boot ROM, so we
will ignore a write and return random garbage on a read. This bug
has been present since 2011, when we did the conversions to the
MemoryRegion APIs, which involved changing all devices from working
with absolute physical addresses to working with offsets within their
MemoryRegions. We must have missed updating these functions.
Replace the uses of these functions in omap_mmc.c with an
open-coded call to qemu_log_mask() and RAZ/WI behaviour.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Pierrick Bouvier [Thu, 15 Jan 2026 15:26:30 +0000 (15:26 +0000)]
target/arm/ptw: make granule_protection_check usable without a cpu
By removing cpu details and use a config struct, we can use the
same granule_protection_check with other devices, like SMMU.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20251216000122.763264-3-pierrick.bouvier@linaro.org
[PMM: avoid local vars in middle of block] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tao Tang [Thu, 15 Jan 2026 15:26:29 +0000 (15:26 +0000)]
target/arm: Move ARMSecuritySpace to a common header
The ARMSecuritySpace enum and its related helpers were defined in the
target-specific header target/arm/cpu.h. This prevented common,
target-agnostic code like the SMMU model from using these definitions
without triggering "cpu.h included from common code" errors.
To resolve this, this commit introduces a new, lightweight header,
include/hw/arm/arm-security.h, which is safe for inclusion by common
code.
The following change was made:
- The ARMSecuritySpace enum and the arm_space_is_secure() and
arm_secure_to_space() helpers have been moved from target/arm/cpu.h
to the new hw/arm/arm-security.h header.
This refactoring decouples the security state definitions from the core
CPU implementation, allowing common hardware models to correctly handle
security states without pulling in heavyweight, target-specific headers.
Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251216000122.763264-2-pierrick.bouvier@linaro.org Link: https://lists.nongnu.org/archive/html/qemu-arm/2025-09/msg01288.html Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
Unfortunately while rebasing the series registering the
ARM/Aarch64 machine interfaces and getting it merged as
commit 38c5ab40031 ("hw/arm: Filter machine types for
qemu-system-arm/aarch64 binaries") we missed the recent
addition of the MAX78000FTHR machine in commit 51eb283dd0e.
Correct that.
The effect is that the machine was accidentally disabled.
Cc: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Tested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251218214306.63667-1-philmd@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3248 Fixes: 38c5ab40031 ("hw/arm: Filter machine types for single binary") Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
julia [Thu, 15 Jan 2026 15:26:29 +0000 (15:26 +0000)]
hw/char/cmsdk-apb-uart.c: log guest_errors for r/w to disabled uart
I don't want to admit how many hours I spent trying to figure out why
nothing was being printed (as the enable-ing code hadn't yet run,
even thought it existed).
Signed-off-by: julia <midnight@trainwit.ch> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251217-cmsdk-uart-disabled-warning2-v1-1-847de48840bc@trainwit.ch Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Jim MacArthur [Thu, 15 Jan 2026 15:26:29 +0000 (15:26 +0000)]
tests: Add test for ASID2 and write/read of feature bits
Test for presence of ASID2; if it is, check FNG1, FNG0, and A2 are
writable, and read value shows the update. If not present, check these
read as RES0.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Jim MacArthur [Thu, 15 Jan 2026 15:26:29 +0000 (15:26 +0000)]
target/arm: Allow writes to FNG1, FNG0, A2
This just allows read/write of three feature bits. ASID is still
ignored. Any writes to TTBR0_EL0 and TTBR1_EL0, including changing
the ASID, will still cause a complete flush of the TLB.
Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Jim MacArthur [Thu, 15 Jan 2026 15:26:29 +0000 (15:26 +0000)]
target/arm: Enable ID_AA64MMFR4_EL1 register
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org> Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
[PMM: add entry to v8_user_idregs[] list also] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Yao Zi [Wed, 14 Jan 2026 07:25:13 +0000 (15:25 +0800)]
hw/loongarch/virt: Don't abort on access to unimplemented IOCSR
Since commit f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface
for misc ops") which adds a call to g_assert_not_reached() in the path
of handling unimplemented IOCSRs, QEMU would abort when the guest
accesses unimplemented IOCSRs.
This is too serious since there's nothing fatal happening in QEMU
itself, and the guest could probably continue running if we give zero as
result for these reads, which also matches the behavior observed on
3A5000M real machine.
Replace the assertion with qemu_log_mask(LOG_UNIMP, ...), it's still
possible to examine unimplemented IOCSR access through "-d unimp"
command line arguments.
Fixes: f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface for misc ops") Signed-off-by: Yao Zi <me@ziyao.cc> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Xianglai Li [Wed, 14 Jan 2026 07:22:00 +0000 (15:22 +0800)]
hw/loongarch/virt: Fix irq allocation failure with pci device from fdt
When we use the -kernel parameter to start an elf format kernel relying on
fdt, we get the following error:
pcieport 0000:00:01.0: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.0: enabling device (0000 -> 0003)
pcieport 0000:00:01.0: PME: Signaling with IRQ 19
pcieport 0000:00:01.0: AER: enabled with IRQ 19
pcieport 0000:00:01.1: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.1: enabling device (0000 -> 0003)
pcieport 0000:00:01.1: PME: Signaling with IRQ 20
pcieport 0000:00:01.1: AER: enabled with IRQ 20
pcieport 0000:00:01.2: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.2: enabling device (0000 -> 0003)
pcieport 0000:00:01.2: PME: Signaling with IRQ 21
pcieport 0000:00:01.2: AER: enabled with IRQ 21
pcieport 0000:00:01.3: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.3: enabling device (0000 -> 0003)
pcieport 0000:00:01.3: PME: Signaling with IRQ 22
pcieport 0000:00:01.3: AER: enabled with IRQ 22
pcieport 0000:00:01.4: of_irq_parse_pci: failed with rc=-22
This is because the description of interrupt-cell is missing in the pcie
irq map. And there is a lack of a description of the interrupt trigger
type. Now it is corrected and the correct interrupt-cell is added in the
pcie irq map.
Refer to the implementation in arm and add some comments.
Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Xianglai Li [Wed, 14 Jan 2026 07:20:15 +0000 (15:20 +0800)]
hw/loongarch/virt: Modify the interrupt trigger type in fdt table
In the loongarch virt fdt file, the interrupt trigger type directly
uses magic numbers. Now, refer to the definitions in the linux kernel and
use macro definitions.
Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmlmFmIUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroOyDAgAiDTglXIUzvbM1AGRcufyjKMzFeaH
# /aI1UrVno0XT0BsxGqOyR2d8EhtDiBXZe0nS0WBc0KtdUFjVDbnzPT4YF9PPDYwY
# 6KOp7dbfCLuK9gmvSPji3rlEsRrGkawy/WwI7HSzpMT2r/yMUBN/mWUqK359NgUI
# mHZkHyyf78wqSYiSsuKs8SRLfEXa2p3u9kH6F7yZ/CWSUO9o8yanu83nVvF2b12K
# m87SBKGJutuJrp266Id5DyArkbn+vIfpT1wTgsRIAWpRSAZFm/t2xSX/6UTQhmtg
# 5kAL7OCkKh/iHePx5JxtVrkFGGffhZeoSToo8amroyZ1SEXCnk/U1Ksiyg==
# =0p8Y
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 13 Jan 2026 08:54:42 PM AEDT
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [unknown]
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
rust: Update Cargo.lock
hw/i386/kvm: fix PIRQ bounds check in xen_physdev_map_pirq()
target/i386/tcg: allow VEX in 16-bit protected mode
target/i386/tcg: mask addresses for VSIB
target/i386/tcg: do not mark all SSE instructions as unaligned
target/i386/tcg: remove dead code
target/i386/tcg: do not leave non-arithmetic flags in CC_SRC after PUSHF
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
# -----BEGIN PGP SIGNATURE-----
#
# iQJGBAABCgAwFiEEzS913cjjpNwuT1Fz8ww4vT8vvjwFAmlmGEASHGxhdXJlbnRA
# dml2aWVyLmV1AAoJEPMMOL0/L748b/QP/19OY8lzZtUazK5RVTNCZVXkRrr2vQBV
# Geey+OywZiCkREbgS5CniQ8mNUMgajY0RCyrDO5Eb7xLffBdXxGBRBpocnAbsQtj
# HJbgPS7Fg8GJKCecgzwHOhkyb6Yy9A9sleijXGq9CUoJaJAwDQGGO1MPm4jUsMVt
# GVjJG8vm3KbVNXCzgLUfHh72wSoE4S8Fn94DNJxCAEb2FC0C5T24+Yf80JA55hgT
# FRnTIbEbrJyOTVvxwZim3Ye3o2/hk3oQcaFd3ugSKXdJh58/DQi1FSAPyVM26DQu
# qXFK5Zaj9VCMpXG8vjd0SUhJWauJ9WXIRGh+S8HHcWBIxqhRxULBCvjTrPzAN2eJ
# VftrYHQe2ruqocSxWMKAIaX8RY/Og58bMwqWDkWj9r9GT3gttFRLISYdry5KS/mS
# NAlEeLNNazatCgldOrdpfvSm7rMLausuqdNgDLG6tRHwxCDR5SQMnj1hHNE+sn2O
# /Ek7gQ+JfzR5nKw1oBlWyv8ZG9DXJXLgjxX/bxR4FC+xp/QOo+ono59Ma9SjHt/2
# zpWXoIm2YgrfzRJbm7NUHnKkbd8titA1EYO9JZ0/EzPAL+pCwx6WQx+/GnxMKjA8
# 42vaRmi9lGcukXQ3gQeHR+wt/s0SOYNGTgK8tcMuDt28yn9iODijmcQSDyLLAVx4
# FNkp9jL4U+fc
# =LQA5
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 13 Jan 2026 09:02:40 PM AEDT
# gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg: issuer "laurent@vivier.eu"
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [unknown]
# gpg: aka "Laurent Vivier <laurent@vivier.eu>" [unknown]
# gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* tag 'm68k-for-11.0-pull-request' of https://github.com/vivier/qemu-m68k:
target/m68k: Improve CHK and CHK2; implement CMP2
m68k: link.l is only available with 68020+
m68k: fix CAS2 writeback when Dc1==Dc2
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Merge tag 'pull-vfio-20260113' of https://github.com/legoater/qemu into staging
vfio queue:
* Resolves build errors with gcc 16
* Adjusts the Linux headers for s390x and mshv
* Fixes endianness issue in the VFIO helper functions
* Adds support for live migration with vIOMMU when using IOMMU
dirty tracking
* Implements a migration blocker to prevent failures when VM
memory is too large
* Corrects an unmap_bitmap failure in the legacy VFIO backend
* Addresses a workaround for an Intel IOMMU errata.
* Implements Intel IOMMU first stage translation for passthrough
device. Also a prerequisite work for vSVA.
* Updates documentation
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmlmEgQACgkQUaNDx8/7
# 7KFm2w/+JwlyiY5jWjzvCBCEEgBdBrb8XzMoSFr2xWNQrNHvE23veeQJcT+5LwQI
# DV74Y3wmWYeAVGGKHVoALVEIJYtjVDOPU5TIyhr4nTMO8/A2j1ylBhsP6ZnWYYkO
# uFe92O3wTHViFY5h9dgm1JsA3Bok52mteAHAE5gsxCNYk6h+ps1a5UZM8wxjtNA2
# yVIvAZvaubnA/0yN02pz5bCOhPpaGpkV69l7nJSHwk2RPuspUR6dWo11P2yjxVDQ
# 7pv7DbLl9qm+xdmOp0ANVPKp9fqBJnBa/ta1Dn1VrQ2iJXnwezy+IdNC1In/HKKy
# ZHe+V/p2JA09xjjmB2fu53DQQIjh/qeCWi0b2vkDZZVvl0hJ+0y9P1GRxhwBhtgK
# /vwvgKGwC3OwXcdrxXNvD4Yy4NJLUtCoN8vmyI41ohLeMfr7/XrmTrf0J4ciPc4T
# 1bAHY2SWkFL59ylN+gt1khlV8zqPYP9S1i08A2wJjvLOwqRJ/LN2tNEh9pWvGmFg
# p5WGTNeZLsfD+ZT10bm083EMAc1va7RTQNjAzb55pxq0ASPl7ZIVAKqazaG9QsaK
# apPxGGYevuWzJVaNYWAqj7y37WDP/w6rKmyRmIBMV+x9+Dv+DGPbGb8oAOjZ0Av5
# 489mHYIONxp//2SvaUSfGpQHACCgEKTHlstdlyw79C84xPzHujE=
# =o9aW
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 13 Jan 2026 08:36:04 PM AEDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@redhat.com>" [full]
# gpg: aka "Cédric Le Goater <clg@kaod.org>" [full]
* tag 'pull-vfio-20260113' of https://github.com/legoater/qemu: (41 commits)
tests/rcutorture: Fix build error
tests/qtest: Fix build error
target/riscv: Fix build errors
ppc/vof: Fix build error
update-linux-headers: Remove "asm-s390/unistd_32.h"
include/hw/hyperv: Remove unused 'struct mshv_vp_registers' definition
util/vfio-helper: Fix endianness in PCI config read/write functions
Workaround for ERRATA_772415_SPR17
vfio/listener: Bypass readonly region for dirty tracking
intel_iommu_accel: Implement get_host_iommu_quirks() callback
hw/pci: Introduce pci_device_get_host_iommu_quirks()
vfio/migration: Allow live migration with vIOMMU without VFs using device dirty tracking
vfio/migration: Add migration blocker if VM memory is too large to cause unmap_bitmap failure
vfio/listener: Add missing dirty tracking in region_del
intel_iommu: Fix unmap_bitmap failure with legacy VFIO backend
vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
vfio: Add a backend_flag parameter to vfio_container_query_dirty_bitmap()
vfio/container-legacy: rename vfio_dma_unmap_bitmap() to vfio_legacy_dma_unmap_get_dirty_bitmap()
vfio/iommufd: Query dirty bitmap before DMA unmap
vfio/iommufd: Add framework code to support getting dirty bitmap before unmap
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Paolo Bonzini [Wed, 31 Dec 2025 11:42:54 +0000 (12:42 +0100)]
target/i386/tcg: remove dead code
Remove dead code; it arose when I noticed that, because 0x3? opcodes do
have a pop, case 0x32 works just fine as fcomp (even though 0x?2 is fcom):
there is no need to hack the op to 0x03.
Paolo Bonzini [Wed, 7 Jan 2026 04:42:38 +0000 (05:42 +0100)]
target/i386/tcg: do not leave non-arithmetic flags in CC_SRC after PUSHF
The value that is pushed by PUSHF is the full EFLAGS, while CC_OP_EFLAGS
only wants arithmetic flags in CC_SRC. To avoid this, follow what other
helpers do and set CC_SRC/CC_OP directly in helper_read_eflags. This
is basically free and fixes an issue booting Windows 3.11.
Reported-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Fixes: e661e2d7a37 ("target/i386/tcg: update cc_op after PUSHF", 2025-12-27) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cédric Le Goater [Mon, 12 Jan 2026 16:33:50 +0000 (17:33 +0100)]
tests/rcutorture: Fix build error
Newer gcc compiler (version 16.0.0 20260103 (Red Hat 16.0.0-0) (GCC))
detects an unused variable error:
../tests/unit/rcutorture.c: In function ‘rcu_read_stress_test’:
../tests/unit/rcutorture.c:251:18: error: variable ‘garbage’ set but not used [-Werror=unused-but-set-variable=]
251 | volatile int garbage = 0;
| ^~~~~~~
Since the 'garbage' variable is used to generate memory reads from the
CPU while holding the RCU lock, it can not be removed. Tag it as
((unused)) instead to silence the compiler warnings/errors.
Cédric Le Goater [Mon, 12 Jan 2026 12:31:46 +0000 (13:31 +0100)]
tests/qtest: Fix build error
Newer gcc compiler (version 16.0.0 20260103 (Red Hat 16.0.0-0) (GCC))
detects an unused variable error:
../tests/qtest/libqtest.c: In function ‘qtest_qom_has_concrete_type’:
../tests/qtest/libqtest.c:1044:9: error: variable ‘idx’ set but not used [-Werror=unused-but-set-variable=]
Cédric Le Goater [Mon, 12 Jan 2026 16:16:26 +0000 (17:16 +0100)]
target/riscv: Fix build errors
Newer gcc compiler (version 16.0.0 20260103 (Red Hat 16.0.0-0) (GCC))
detects a truncation error:
../target/riscv/cpu.c: In function ‘riscv_isa_write_fdt’:
../target/riscv/cpu.c:2916:35: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=]
2916 | snprintf(isa_base, maxlen, "rv%di", xlen);
| ^~
../target/riscv/cpu.c:2916:32: note: directive argument in the range [-2147483648, 2147483632]
2916 | snprintf(isa_base, maxlen, "rv%di", xlen);
| ^~~~~~~
Since the xlen variable represents the register width (32, 64, 128) in
the RISC-V base ISA name, mask its value with a 8-bit bitmask to
satisfy the size constraints on the snprintf output.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <alistair.francis@wdc.com> Cc: Weiwei Li <liwei1518@gmail.com> Cc: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: Liu Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260112161626.1232639-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Cédric Le Goater [Mon, 12 Jan 2026 12:47:22 +0000 (13:47 +0100)]
ppc/vof: Fix build error
Newer gcc compiler (version 16.0.0 20260103 (Red Hat 16.0.0-0) (GCC))
detects an unused variable error:
../hw/ppc/vof.c: In function ‘vof_dt_memory_available’:
../hw/ppc/vof.c:642:12: error: variable ‘n’ set but not used [-Werror=unused-but-set-variable=]
The "asm/unistd_32.h" file was generated for the 31-bit compatibility
mode on the s390 architecture and support was removed in v6.19-rc1,
commit 4ac286c4a8d9 ("s390/syscalls: Switch to generic system call
table generation")
unistd_32.h is no longer generated when running make header_install.
Remove it.
Reported-by: Shameer Kolothum <skolothumtho@nvidia.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260112155341.1209988-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Farhan Ali [Mon, 5 Jan 2026 22:20:29 +0000 (14:20 -0800)]
util/vfio-helper: Fix endianness in PCI config read/write functions
The VFIO pread/pwrite functions use little-endian data format. Currently, the
qemu_vfio_pci_read_config() and qemu_vfio_pci_write_config() don't correctly
convert from CPU native endian format to little-endian (and vice versa) when
using the pread/pwrite functions. Fix this by limiting read/write to 32 bits
and handling endian conversion in qemu_vfio_pci_read_config() and
qemu_vfio_pci_write_config().
Zhenzhong Duan [Tue, 6 Jan 2026 06:28:06 +0000 (01:28 -0500)]
Workaround for ERRATA_772415_SPR17
On a system influenced by ERRATA_772415, IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17
is repored by IOMMU_DEVICE_GET_HW_INFO. Due to this errata, even the readonly
range mapped on second stage page table could still be written.
Reference from 4th Gen Intel Xeon Processor Scalable Family Specification
Update, Errata Details, SPR17.
Link https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/eagle-stream/sapphire-rapids-specification-update/
Backup https://cdrdv2.intel.com/v1/dl/getContent/772415
Also copied the SPR17 details from above link:
"Problem: When remapping hardware is configured by system software in
scalable mode as Nested (PGTT=011b) and with PWSNP field Set in the
PASID-table-entry, it may Set Accessed bit and Dirty bit (and Extended
Access bit if enabled) in first-stage page-table entries even when
second-stage mappings indicate that corresponding first-stage page-table
is Read-Only.
Implication: Due to this erratum, pages mapped as Read-only in second-stage
page-tables may be modified by remapping hardware Access/Dirty bit updates.
Workaround: None identified. System software enabling nested translations
for a VM should ensure that there are no read-only pages in the
corresponding second-stage mappings."
Introduce a helper vfio_device_get_host_iommu_quirk_bypass_ro to check if
readonly mappings should be bypassed.
Zhenzhong Duan [Tue, 6 Jan 2026 06:28:05 +0000 (01:28 -0500)]
vfio/listener: Bypass readonly region for dirty tracking
When doing dirty tracking or calculating dirty tracking range, readonly
regions can be bypassed, because corresponding DMA mappings are readonly
and never become dirty.
This can optimize dirty tracking a bit for passthrough device.
Implement get_host_iommu_quirks() callback to retrieve the vendor specific
hardware information data and convert it into bitmaps defined with enum
host_iommu_quirks. It will be used by VFIO in subsequent patch.
In VFIO core, we call iommufd_backend_get_device_info() to return vendor
specific hardware information data, but it's not good to retrieve this raw
data in VFIO core.
Introduce a new PCIIOMMUOps optional callback, get_host_iommu_quirk() which
allows to retrieve the vendor specific hardware information data and convert
it into bitmaps defined with enum host_iommu_quirks.
pci_device_get_host_iommu_quirks() is a wrapper that can be called on a PCI
device potentially protected by a vIOMMU.
Zhenzhong Duan [Thu, 18 Dec 2025 06:26:30 +0000 (01:26 -0500)]
vfio/migration: Allow live migration with vIOMMU without VFs using device dirty tracking
Commit e46883204c38 ("vfio/migration: Block migration with vIOMMU")
introduces a migration blocker when vIOMMU is enabled, because we need
to calculate the IOVA ranges for device dirty tracking. But this is
unnecessary for iommu dirty tracking.
Limit the vfio_viommu_preset() check to those devices which use device
dirty tracking. This allows live migration with VFIO devices which use
iommu dirty tracking.
Suggested-by: Jason Zeng <jason.zeng@intel.com> Co-developed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Tested-by: Giovannio Cabiddu <giovanni.cabiddu@intel.com> Tested-by: Rohith S R <rohith.s.r@intel.com> Link: https://lore.kernel.org/qemu-devel/20251218062643.624796-10-zhenzhong.duan@intel.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Zhenzhong Duan [Thu, 18 Dec 2025 06:26:29 +0000 (01:26 -0500)]
vfio/migration: Add migration blocker if VM memory is too large to cause unmap_bitmap failure
With default config, kernel VFIO IOMMU type1 driver limits dirty bitmap to
256MB for unmap_bitmap ioctl so the maximum guest memory region is no more
than 8TB size for the ioctl to succeed.
Be conservative here to limit total guest memory to max value supported
by unmap_bitmap ioctl or else add a migration blocker. IOMMUFD backend
doesn't have such limit, one can use it if there is a need to migrate such
large VM.
Zhenzhong Duan [Thu, 18 Dec 2025 06:26:28 +0000 (01:26 -0500)]
vfio/listener: Add missing dirty tracking in region_del
If a VFIO device in guest switches from passthrough(PT) domain to block
domain, the whole memory address space is unmapped, but we passed a NULL
iotlb entry to unmap_bitmap, then bitmap query didn't happen and we lost
dirty pages.
By constructing an iotlb entry with iova = gpa for unmap_bitmap, it can
set dirty bits correctly.
For IOMMU address space, we still send NULL iotlb because VFIO don't know
the actual mappings in guest. It's vIOMMU's responsibility to send actual
unmapping notifications, e.g., vtd_address_space_unmap_in_dirty_tracking().
Zhenzhong Duan [Thu, 18 Dec 2025 06:26:27 +0000 (01:26 -0500)]
intel_iommu: Fix unmap_bitmap failure with legacy VFIO backend
If a VFIO device in guest switches from IOMMU domain to block domain,
vtd_address_space_unmap() is called to unmap whole address space.
If that happens during migration, migration fails with legacy VFIO
backend as below:
Status: failed (vfio_container_dma_unmap(0x561bbbd92d90, 0x100000000000, 0x100000000000) = -7 (Argument list too long))
Because legacy VFIO limits maximum bitmap size to 256MB which maps to 8TB on
4K page system, when 16TB sized UNMAP notification is sent, unmap_bitmap
ioctl fails. Normally such large UNMAP notification come from IOVA range
rather than system memory.
Apart from that, vtd_address_space_unmap() sends UNMAP notification with
translated_addr = 0, because there is no valid translated_addr for unmapping
a whole iommu memory region. This breaks dirty tracking no matter which VFIO
backend is used.
Fix them all by iterating over DMAMap list to unmap each range with active
mapping when global_dirty_tracking is active. global_dirty_tracking is
protected by BQL, so it's safe to reference it directly. If it's not active,
unmapping the whole address space in one go is optimal.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Giovannio Cabiddu <giovanni.cabiddu@intel.com> Tested-by: Rohith S R <rohith.s.r@intel.com> Link: https://lore.kernel.org/qemu-devel/20251218062643.624796-7-zhenzhong.duan@intel.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Zhenzhong Duan [Thu, 18 Dec 2025 06:26:26 +0000 (01:26 -0500)]
vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
Pass IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR when doing the last dirty
bitmap query right before unmap, no PTEs flushes. This accelerates the
query without issue because unmap will tear down the mapping anyway.
Co-developed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Tested-by: Xudong Hao <xudong.hao@intel.com> Tested-by: Giovannio Cabiddu <giovanni.cabiddu@intel.com> Tested-by: Rohith S R <rohith.s.r@intel.com> Link: https://lore.kernel.org/qemu-devel/20251218062643.624796-6-zhenzhong.duan@intel.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
projects / thirdparty / qemu.git / log
