Allow later commits to include only the "new" tcg/helper.h, thus
preventing to pull aarch64 helpers (+ target/arm/helper.h contains a
ifdef TARGET_AARCH64).
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-16-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
It could be squashed with commit introducing it, but I would prefer to
introduce target/arm/cpu.c first.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-12-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Need to stub cpu64 finalize functions.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-10-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Call is guarded by is_a64(env), so it's safe to expose without needing
to assert anything.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-9-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-8-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Allow to get rid of CONFIG_KVM in target/arm/cpu.c
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250512180502.2395029-7-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Needed in target/arm/cpu.c once kvm is possible.
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: 20250512180502.2395029-6-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add a forward decl for struct kvm_vcpu_init to avoid pulling all kvm
headers.
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: 20250512180502.2395029-5-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The TYPE_AARCH64_CPU class is an abstract type that is the parent of
all the AArch64 CPUs. It now has no special behaviour of its own, so
we can eliminate it and make the AArch64 CPUs directly inherit from
TYPE_ARM_CPU.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250429132200.605611-8-peter.maydell@linaro.org
We want to merge TYPE_AARCH64_CPU with TYPE_ARM_CPU, so enforcing in
kvm_arch_init_vcpu() that the CPU class is a subclass of
TYPE_AARCH64_CPU will no longer be possible.
It's safe to just remove this test, because any purely-AArch32 CPU
will fail the "kvm_target isn't set" check, because we no longer
support the old AArch32-host KVM setup and so CPUs like the Cortex-A7
no longer set cpu->kvm_target. Only the 'host', 'max', and the
odd special cases 'cortex-a53' and 'cortex-a57' set kvm_target.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250429132200.605611-7-peter.maydell@linaro.org
The only thing we have left in the TYPE_AARCH64_CPU class that makes
it different to TYPE_ARM_CPU is that we register the handling of the
"aarch64" property there.
Move the handling of this property to the base class, where we make
it a property of the object rather than of the class, and add it
to the CPU if it has the ARM_FEATURE_AARCH64 property present at
init. This is in line with how we handle other Arm CPU properties,
and should not change which CPUs it's visible for.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250429132200.605611-6-peter.maydell@linaro.org
Currently we provide an AArch64 gdbstub for CPUs which are
TYPE_AARCH64_CPU, and an AArch32 gdbstub for those which are only
TYPE_ARM_CPU. This mostly does the right thing, except in the
corner case of KVM with -cpu host,aarch64=off. That produces a CPU
which is TYPE_AARCH64_CPU but which has ARM_FEATURE_AARCH64 removed
and which to the guest is in AArch32 mode.
Now we have moved all the handling of AArch64-vs-AArch32 gdbstub
behaviour into TYPE_ARM_CPU we can change the condition we use for
whether to select the AArch64 gdbstub to look at ARM_FEATURE_AARCH64.
This will mean that we now correctly provide an AArch32 gdbstub for
aarch64=off CPUs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250429132200.605611-5-peter.maydell@linaro.org
Currently the microblaze code calls gdb_register_coprocessor() in its
initfn. This works, but we would like to delay setting up GDB
registers until realize. All other target architectures only call
gdb_register_coprocessor() in realize, after the call to
cpu_exec_realizefn().
Move the microblaze gdb_register_coprocessor() use, bringing it
in line with other targets.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250429132200.605611-3-peter.maydell@linaro.org
We're about to make a change that removes the only other use
of the 'cpu' local variable in mb_cpu_initfn(); since the
DEVICE() casts work fine with the Object*, use that instead,
so that we can remove the local variable when we make the
following change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250429132200.605611-2-peter.maydell@linaro.org
While Bochs's algorithms are pretty solid, there are small opportunities
to improve them or to make their logic more similar to TCG's handling
of condition codes.
- use a single bit for the difference between bits 0..7 of result and PF.
This is useful because "set only ZF" is not a common case.
- place SD in the same place as SF
- move CF and PO at bits 62 and 63 when target_ulong is 64-bits wide,
so that 64-bit ALU operations need fewer shifts
- use rotates to move CF and AF from auxbits to their eflags position
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
decode->op[N].ptr can contain either a host pointer (!) in CPUState
or a guest virtual address. Pass the whole struct to read_val_ext
and write_val_ext, so that it can decide the contents based on the
operand type.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that we can do so after the error code has been pushed, raising
the #DB exception for task-switch traps is trivial.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Allow using plugins on BSD user-emulation
- Inline VMSTATE_CPU() macro
- Fix header includes for HVF x86
- Build hw/hyperv/ files once
- Various typo fixed
- Fix issue in i.MX I2C model
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmgco7IACgkQ4+MsLN6t
wN5b/RAAvI+0Fyo/QNTjUQKBsFT7M9DY2bv2rxElG5+gwQvrqRkwV4POjJ42TFbl
NazNnywIW2eZvjQ1W3pBceiAhXAOxRi/zSTRO30uhL0DFmfAIEF6aMZdVZKg01mq
U/x5WF3WM8taXYE5V8kgV+Rr6b02SMGgtUcNVTnDjVdmRI0+ByPf122IwniKffhR
kJhPj4tgU/wBsOisgPTAr1kbQePyvbvckxKc1kt73jPRV6fUtVV14qcrBN6zECV3
+uFit6Q/zYH21XpFdq/3X9lEjMZNGI6zBZ939/x5Bpj53MjmYovYY81987ioAB7S
zsmFZ2Nl7L/8l/jKrhKPS+l71OzmLI1dMzr2CrOxgMhXxfItta9y04CLDf7ZXSf6
mgDE3rA89C33dzoGnb4axphmcposyM/u0lLhGgnMh3GFv84P6/DqgxKZv8vj6OMq
U/DhHPw507W/JAg8ge/5YchVJwxKfBbHm0y7NLqH1IGmoyyqsMQo6DbC9/zTK7T4
dAZdcrm2dBbSxYaL5J8gTGPo/QjVG9BaU9EvKIcZf181QSHg//QCYB6iN5Phx5hO
KH9hUTmpqA4Lza0XGGUM1c43/24Dq/i1I0EncW4zqFqaf9l9M06i5cdQrU+myzAs
O/dLsFlm7WAJLDkt2Ax2peYKHVKpGywFRsCR04uulkoLoD5nd/w=
=1VOP
-----END PGP SIGNATURE-----
Merge tag 'hw-misc-20250508' of https://github.com/philmd/qemu into staging
Misc HW patches
- Allow using plugins on BSD user-emulation
- Inline VMSTATE_CPU() macro
- Fix header includes for HVF x86
- Build hw/hyperv/ files once
- Various typo fixed
- Fix issue in i.MX I2C model
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmgco7IACgkQ4+MsLN6t
# wN5b/RAAvI+0Fyo/QNTjUQKBsFT7M9DY2bv2rxElG5+gwQvrqRkwV4POjJ42TFbl
# NazNnywIW2eZvjQ1W3pBceiAhXAOxRi/zSTRO30uhL0DFmfAIEF6aMZdVZKg01mq
# U/x5WF3WM8taXYE5V8kgV+Rr6b02SMGgtUcNVTnDjVdmRI0+ByPf122IwniKffhR
# kJhPj4tgU/wBsOisgPTAr1kbQePyvbvckxKc1kt73jPRV6fUtVV14qcrBN6zECV3
# +uFit6Q/zYH21XpFdq/3X9lEjMZNGI6zBZ939/x5Bpj53MjmYovYY81987ioAB7S
# zsmFZ2Nl7L/8l/jKrhKPS+l71OzmLI1dMzr2CrOxgMhXxfItta9y04CLDf7ZXSf6
# mgDE3rA89C33dzoGnb4axphmcposyM/u0lLhGgnMh3GFv84P6/DqgxKZv8vj6OMq
# U/DhHPw507W/JAg8ge/5YchVJwxKfBbHm0y7NLqH1IGmoyyqsMQo6DbC9/zTK7T4
# dAZdcrm2dBbSxYaL5J8gTGPo/QjVG9BaU9EvKIcZf181QSHg//QCYB6iN5Phx5hO
# KH9hUTmpqA4Lza0XGGUM1c43/24Dq/i1I0EncW4zqFqaf9l9M06i5cdQrU+myzAs
# O/dLsFlm7WAJLDkt2Ax2peYKHVKpGywFRsCR04uulkoLoD5nd/w=
# =1VOP
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 May 2025 08:29:38 EDT
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'hw-misc-20250508' of https://github.com/philmd/qemu:
hw/i2c/imx: Always set interrupt status bit if interrupt condition occurs
hw/i386/acpi-build: Fix typo and grammar in comment
hw/i386/acpi-build: Update document reference
hw/i386/acpi-build: Fix build_append_notfication_callback typo
hw/acpi/ged: Fix wrong identation
hw/pci/pcie_port: Fix pcie_slot_is_hotpluggbale_bus typo
hw/hyperv/hyperv: common compilation unit
hw/hyperv/hyperv_testdev: common compilation unit
hw/hyperv/balloon: common balloon compilation units
hw/hyperv/syndbg: common compilation unit
hw/hyperv/vmbus: common compilation unit
hw/hyperv/hyperv.h: header cleanup
hw/hyperv/hv-balloon-stub: common compilation unit
system/hvf: Expose hvf_enabled() to common code
system/hvf: Avoid including 'cpu.h'
accel/hvf: Include missing 'hw/core/cpu.h' header
target/migration: Inline VMSTATE_CPU()
qom: Factor qom_resolve_path() out
bsd-user: add option to enable plugins
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
VMSTATE_CPU() is only used in 4 places and doesn't provide
much, directly inline it using VMSTATE_STRUCT().
This removes the last COMPILING_PER_TARGET in "hw/core/cpu.h".
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250429085148.11876-1-philmd@linaro.org>
Our KVM code includes backwards compatibility support for ancient
kernels which don't support the KVM_ARM_PREFERRED_TARGET ioctl. This
ioctl was introduced in kernel commit 42c4e0c77ac91 in September
2013 and is in v3.12, so it's reasonable to assume it's present.
(We already dropped support for kernels without KVM_CAP_DEVICE_CTRL,
a feature added to the kernel in April 2013, in our commit
84f298ea3e; so there are only about six months' worth of kernels,
from v3.9 to v3.11, that we don't already fail to run on and that
this commit is dropping handling for.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250318114222.1018200-1-peter.maydell@linaro.org
If the guest code has an ISB or SB insn inside an IT block, we
generate incorrect code which trips a TCG assertion:
qemu-system-arm: ../tcg/tcg-op.c:3343: void tcg_gen_goto_tb(unsigned int): Assertion `(tcg_ctx->goto_tb_issue_mask & (1 << idx)) == 0' failed.
This is because we call gen_goto_tb(dc, 1, ...) twice:
brcond_i32 ZF,$0x0,ne,$L1
add_i32 pc,pc,$0x4
goto_tb $0x1
exit_tb $0x73d948001b81
set_label $L1
add_i32 pc,pc,$0x4
goto_tb $0x1
exit_tb $0x73d948001b81
Both calls are in arm_tr_tb_stop(), one for the
DISAS_NEXT/DISAS_TOO_MANY handling, and one for the dc->condjump
condition-failed codepath. The DISAS_NEXT handling doesn't have this
problem because arm_post_translate_insn() does the handling of "emit
the label for the condition-failed conditional execution" and so
arm_tr_tb_stop() doesn't have dc->condjump set. But for
DISAS_TOO_MANY we don't do that.
Fix the bug by making arm_post_translate_insn() handle the
DISAS_TOO_MANY case. This only affects the SB and ISB insns when
used in Thumb mode inside an IT block: only these insns specifically
set is_jmp to TOO_MANY, and their A32 encodings are unconditional.
For the major TOO_MANY case (breaking the TB because it would cross a
page boundary) we do that check and set is_jmp to TOO_MANY only after
the call to arm_post_translate_insn(); so arm_post_translate_insn()
sees is_jmp == DISAS_NEXT, and we emit the correct code for that
situation.
With this fix we generate the somewhat more sensible set of TCG ops:
brcond_i32 ZF,$0x0,ne,$L1
set_label $L1
add_i32 pc,pc,$0x4
goto_tb $0x1
exit_tb $0x7c5434001b81
(NB: the TCG optimizer doesn't optimize out the jump-to-next, but
we can't really avoid emitting it because we don't know at the
point we're emitting the handling for the condexec check whether
this insn is going to happen to be a nop for us or not.)
Cc: qemu-stable@nongnu.org
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2942
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250501125544.727038-1-peter.maydell@linaro.org
On Emscripten, function pointer casts can result in runtime failures due to
strict function signature checks. This affects the use of g_list_sort and
g_slist_sort, which internally perform function pointer casts that are not
supported by Emscripten. To avoid these issues, g_list_sort_with_data and
g_slist_sort_with_data should be used instead, as they do not rely on
function pointer casting.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/e91c4e266b839f62b5c41173a05896b210ae1180.1745820062.git.ktokunaga.mail@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Emscripten, function pointer casts can result in runtime failures due to
strict function signature checks. This affects the use of g_list_sort and
g_slist_sort, which internally perform function pointer casts that are not
supported by Emscripten. To avoid these issues, g_list_sort_with_data and
g_slist_sort_with_data should be used instead, as they do not rely on
function pointer casting.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Link: https://lore.kernel.org/r/d917055d35f5ff7316ccdcbdf57af9a7bd85bf29.1745820062.git.ktokunaga.mail@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Emscripten, function pointer casts can result in runtime failures due to
strict function signature checks. This affects the use of g_list_sort and
g_slist_sort, which internally perform function pointer casts that are not
supported by Emscripten. To avoid these issues, g_list_sort_with_data and
g_slist_sort_with_data should be used instead, as they do not rely on
function pointer casting.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Link: https://lore.kernel.org/r/8ee6c2b02c97d5db358c3eb290d00afe71d1ceb7.1745820062.git.ktokunaga.mail@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Emscripten, function pointer casts can result in runtime failures due to
strict function signature checks. This affects the use of g_list_sort and
g_slist_sort, which internally perform function pointer casts that are not
supported by Emscripten. To avoid these issues, g_list_sort_with_data and
g_slist_sort_with_data should be used instead, as they do not rely on
function pointer casting.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Link: https://lore.kernel.org/r/7d56c82382e8b4f1694b6d7883b2ce3084fdc72d.1745820062.git.ktokunaga.mail@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It was reported that QEMU monitor command gva2gpa was reporting unmapped
memory for a valid access (qemu-system-aarch64), during a copy from
kernel to user space (__arch_copy_to_user symbol in Linux) [1].
This was affecting cpu_memory_rw_debug also, which
is used in numerous places in our codebase. After investigating, the
problem was specific to arm_cpu_get_phys_page_attrs_debug.
When performing user access from a privileged space, we need to do a
second lookup for user mmu idx, following what get_a64_user_mem_index is
doing at translation time.
[1] https://lists.nongnu.org/archive/html/qemu-discuss/2025-04/msg00013.html
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250414153027.1486719-5-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Allow to call that function easily several times in next commit.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250414153027.1486719-4-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
It should be equivalent to previous code.
Allow to call common function to get a page address later.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250414153027.1486719-3-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We'll reuse this function later.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20250414153027.1486719-2-pierrick.bouvier@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hvf_arch_set_traps is already called from a context of a specific
CPUState, so we don't need to do a nested CPU_FOREACH.
It also results in an error from hv_vcpu_set_sys_reg, as it may only be
called from the thread owning the vCPU.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2895
Tested-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Mads Ynddal <m.ynddal@samsung.com>
Reported-by: Daniel Gomez <da.gomez@samsung.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250402135229.28143-2-mads@ynddal.dk
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This macro is used by only one target, and even then under
unusual conditions -- AArch64 with mmap's PROT_MTE flag.
Since page size for aarch64-linux-user is variable, the
per-page data size is also variable.
Since page_reset_target_data via target_munmap does not
have ready access to CPUState, simply pass in the size
from the first allocation and remember that.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
