The test case in the ppe42 functional test triggers a TCG debug
assertion, which causes the test to fail in an --enable-debug
build or when the sanitizers are enabled:
#6 0x00007ffff4a3b517 in __assert_fail
(assertion=0x5555562e7589 "!temp_readonly(ots)", file=0x5555562e5b23 "../../tcg/tcg.c", line=4928, function=0x5555562e8900 <__PRETTY_FUNCTION__.23> "tcg_reg_alloc_mov") at ./assert/assert.c:105
#7 0x0000555555cc2189 in tcg_reg_alloc_mov (s=0x7fff60000b70, op=0x7fff600126f8) at ../../tcg/tcg.c:4928
#8 0x0000555555cc74e0 in tcg_gen_code (s=0x7fff60000b70, tb=0x7fffa802f540, pc_start=4294446080) at ../../tcg/tcg.c:6667
#9 0x0000555555d02abe in setjmp_gen_code
(env=0x555556cbe610, tb=0x7fffa802f540, pc=4294446080, host_pc=0x7fffeea00c00, max_insns=0x7fffee9f9d74, ti=0x7fffee9f9d90)
at ../../accel/tcg/translate-all.c:257
#10 0x0000555555d02d75 in tb_gen_code (cpu=0x555556cba590, s=...) at ../../accel/tcg/translate-all.c:325
#11 0x0000555555cf5922 in cpu_exec_loop (cpu=0x555556cba590, sc=0x7fffee9f9ee0) at ../../accel/tcg/cpu-exec.c:970
#12 0x0000555555cf5aae in cpu_exec_setjmp (cpu=0x555556cba590, sc=0x7fffee9f9ee0) at ../../accel/tcg/cpu-exec.c:1016
#13 0x0000555555cf5b4b in cpu_exec (cpu=0x555556cba590) at ../../accel/tcg/cpu-exec.c:1042
#14 0x0000555555d1e7ab in tcg_cpu_exec (cpu=0x555556cba590) at ../../accel/tcg/tcg-accel-ops.c:82
#15 0x0000555555d1ff97 in rr_cpu_thread_fn (arg=0x555556cba590) at ../../accel/tcg/tcg-accel-ops-rr.c:285
#16 0x00005555561586c9 in qemu_thread_start (args=0x555556ee3c90) at ../../util/qemu-thread-posix.c:393
#17 0x00007ffff4a9caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#18 0x00007ffff4b29c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
This can be reproduced "by hand":
./build/clang/qemu-system-ppc -display none -vga none \
-machine ppe42_machine -serial stdio \
-device loader,file=$HOME/.cache/qemu/download/03c1ac0fb7f6c025102a02776a93b35101dae7c14b75e4eab36a337e39042ea8 \
-device loader,addr=0xfff80040,cpu-num=0
(assuming you have the image file from the functional test
in your local cache).
This happens for this input:
IN:
0xfff80c00: 07436004 .byte 0x07, 0x43, 0x60, 0x04
which generates (among other things):
not_i32 $0x80000,$0x80000
which the TCG optimization pass turns into:
mov_i32 $0x80000,$0xfff7ffff dead: 1 pref=0xffff
and where we then assert because we tried to write to a constant.
This happens for the CLRBWIBC instruction which ends up in
do_mask_branch() with rb_is_gpr false and invert true. In this case
we will generate code that sets mask to a tcg_constant_tl() but then
uses it as the LHS in tcg_gen_not_tl().
Fix the assertion by doing the invert in the translate time C code
for the "mask is constant" case.
Cc: qemu-stable@nongnu.org
Fixes: f7ec91c239 ("target/ppc: Add IBM PPE42 special instructions")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260212150753.1749448-1-peter.maydell@linaro.org
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Keep ppc-qmp-cmds.c for QMP, use monitor.c for HMP.
Since ppc-qmp-cmds.c was introduced using the MIT license
(see commit bf95728400 "monitor: remove target-specific
code from monitor.c") retain the same license for the new
monitor.c file.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260219191955.83815-22-philmd@linaro.org>
All these registers are already provided by via gdbstub parsed XML
and handler by the gdb_get_register() helper in the monitor/hmp.c
file. Remove as now unreachable code.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260219191955.83815-21-philmd@linaro.org>
This commit removes TARGET_INSN_START_EXTRA_WORDS and force all arch to
call the same version of tcg_gen_insn_start, with additional 0 arguments
if needed. Since all arch have a single call site (in translate.c), this
is as good documentation as having a single define.
The notable exception is target/arm, which has two different translate
files for 32/64 bits. Since it's the only one, we accept to have two
call sites for this.
As well, we update parameter type to use uint64_t instead of
target_ulong, so it can be called from common code.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20260219040150.2098396-15-pierrick.bouvier@linaro.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The CPUClass::disas_set_info() handler is meant to initialize
the %disassemble_info structure; it shoudn't alter the CPU state.
Enforce the CPUState can not be modified by having the handler
take a const pointer.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260202222412.24923-8-philmd@linaro.org>
In preparation of removing the cpu_ldl_code wrapper, inline it.
Get the runtime endianness with ppc_data_endian_env(), passing it
to cpu_ldl_code_mmu(). No need to swap versus qemu-system binary
anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260202210106.93257-12-philmd@linaro.org>
Rather than using a boolean with translator_ldl_swap(),
get the MemOp endianness with ppc_code_endian() and pass
it to translator_ldl_end().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260202210106.93257-8-philmd@linaro.org>
Introduce the ppc_code_endian_dc() helper which returns the
MemOp endianness for the CODE path.
Use it in need_byteswap(), removing one TARGET_BIG_ENDIAN.
Note, the target MemOp endianness can be evaluated as (see
commit 5c43a750b6 "accel/tcg: Implement translator_ld*_end"):
MO_TE ^ (do_swap * MO_BSWAP)
For PPC we use the DisasContext::le_mode field to swap the
default (big-endian) order, so to get the PPC MemOp endianness
we can directly use:
MO_BE ^ (ctx->le_mode * MO_BSWAP)
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-ID: <20260202210106.93257-7-philmd@linaro.org>
Introduce ppc_data_endian_env() which returns the endian MemOp
of the data path from the vCPU env pointer. Keep it hardcoded
as MO_TE, the target built-time endianness.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-ID: <20260202210106.93257-6-philmd@linaro.org>
In preparation of removing the cpu_ld*_data_ra() and
cpu_st*_data_ra() calls, inline them. No logical change
intended.
We note the page translation hash address is expected to
be aligned, so the MO_UNALN flag is misleading. Next commit
will remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260202210106.93257-4-philmd@linaro.org>
Inline the cpu_ldl_data_ra() call in preparation of
removing it. Since the returned value is discarded,
don't bother to set the access endianness.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Message-Id: <20260202210106.93257-2-philmd@linaro.org>
The commit referenced (from QEMU 10.0) has changed the way the pseries
machine marks a cpu as quiesced. Previously, the cpu->halted value
from QEMU common cpu code was (incorrectly) used. With the fix, the
env->quiesced variable starts being used, which improves on the
original situation, but also causes a side effect after migration:
The env->quiesced is set at reset and never migrated, which causes the
destination QEMU to stop delivering interrupts and hang the machine.
To fix the issue from this point on, start migrating the env->quiesced
value.
For QEMU versions < 10.0, sending the new element on the stream would
cause migration to be aborted, so add the appropriate compatibility
property to omit the new subsection.
Independently of this patch, all migrations from QEMU versions < 10.0
would result in a hang since the older QEMU never migrates
env->quiesced. This is bad because it leaves machines already running
on the old QEMU without a migration path into newer versions.
As a workaround, use a few heuristics to infer the new value of
env->quiesced based on cpu->halted, LPCR and PSSCR bits that are
usually set/cleared along with quiesced.
Note that this was tested with -cpu power9 and -machine ic-mode=xive
due to another bug affecting migration of XICS guests. Tested both
forward and backward migration and savevm/loadvm from 9.2 and 10.0.
Also tested loadvm of a savevm image that contains a mix of cpus both
halted and not halted.
Reported-by: Fabian Vogt <fvogt@suse.de>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3079
Fixes: fb802acdc8 ("ppc/spapr: Fix RTAS stopped state")
Acked-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/qemu-devel/20260109123519.28703-2-farosas@suse.de
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Use error_setg_errno() instead of passing the value of strerror() or
g_strerror() to error_setg().
The separator between the error message proper and the value of
strerror() changes from " : ", "", " - ", "- " to ": " in places.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20251121121438.1249498-14-armbru@redhat.com>
Acked-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Move RAMBlock functions out of ram_addr.h and cpu-common.h;
move memory API headers out of include/exec and into include/system.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ppc queue for 10.2
* Firmware updates for SLOF, sam460ex u-boot
* Removal of unusable e200 CPUs
* Coverity fixes for fadump
* Other minor fixes, cleanups for pegasos, spapr.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEa4EM1tK+EPOIPSFCRUTplPnWj7sFAmkDH0MACgkQRUTplPnW
# j7tRjQ/+JbtHt8v4liav4EXRMvM0b8ASDQZFtltC8cg/vpgy/CbYgqcltQDKC4+F
# NjBwSR4mKMTLX95LQsdFCLZY6FENKCirjpsCvHDxU9Hw/UdsVA12rFd/+lgytrTe
# yvJzyhUAoUMSFgpYGZSRQVV+eMEMgHBZekR2RLXwEeuLf/TOAdG+giCMM92Xs7bz
# petdqCspKvpw8RHjb2nyIh67RQ3zYVisU9/pczoNRytjQHYgllddXRt1/DOdF/Gi
# zREc7qE3biDg5jYgWScByy6EwBBBPqNbvR1GLjMV2rM77785KD9GsIzKCCzg6YQY
# CSN/fy8V4TXVkJn8nY2s3SHvBz3szNSvx/nL8sCyKXol/5Naha5CLN0ykz5VcrIf
# 9gNwifW22lHbAtvbmRY9yuTrao8RoQwEZ/3o8Te3W/U9iCFLnwCmKWb/3GT6i/kw
# yyJlUBuW5WASf5N+G0N7IB5BAwzoQQtd0WXW1ugXAFG+Bd/nkRvVkIf9sPWUxWJ/
# 0Tx+2rPZOFzju8VYO8188wh/zDLuNRTEdfo+L21GMI2OBBEUO2nIiwPTLIMrCT4e
# ycC7Vvyu3IahX9ojIL9g0RhPH4K4JDbQuDnszp9SBGcgJYzwLh5Hb436A30A6qJE
# 7r5FTCiwtG27eMKCeZU3iBGpcj+g4kWIvmYEITsyCl8CxKv5+fs=
# =fzVo
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 30 Oct 2025 09:18:11 AM CET
# gpg: using RSA key 6B810CD6D2BE10F3883D21424544E994F9D68FBB
# gpg: Good signature from "Harsh Prateek Bora <harsh.prateek.bora@gmail.com>" [undefined]
# gpg: aka "Harsh Prateek Bora <harshpb@linux.ibm.com>" [undefined]
# 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: 6B81 0CD6 D2BE 10F3 883D 2142 4544 E994 F9D6 8FBB
* tag 'pull-ppc-for-10.2-d4-20251030' of https://gitlab.com/harshpb/qemu:
hw/ppc/pegasos: Update documentation for pegasos1
hw/ppc/pegasos2: Rename to pegasos
hw/ppc/pegasos2: Add /chosen/stdin node with VOF
hw/ppc: Fix memory leak in get_cpu_state_data()
hw/ppc: Fix missing return on allocation failure
ppc/spapr: Cleanup MSI IRQ number handling
target/ppc: Remove the unusable e200 CPUs
target/ppc/cpu_init: Simplify the setup of the TLBxCFG SPR registers
hw/ppc/sam460ex: Update u-boot-sam460ex
pseries: Update SLOF firmware image to release 20251027
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
There is currently no machine in QEMU (except the "none" machine)
that can be run with with one of the e200 ppc CPUs - all machines
either complain about an invalid CPU type or crash QEMU immediately.
Looking at the history of this CPU type, it seems like it has never
been used in QEMU and only implemented as a placeholder (see e.g. the
comment about unimplemented instructions in the POWERPC_FAMILY(e200)
section of cpu_init.c). Being completely unused and unusable since
such a long time, let's just remove it now (without deprecation phase,
since there were no users of this dead code anyway).
Note: The init_excp_e200() is used by the e500 CPUs, too, so we
rename this function to init_excp_e500() instead of removing it.
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20251024065726.738005-3-thuth@redhat.com
Message-ID: <20251024065726.738005-3-thuth@redhat.com>
The next commit is going to remove init_proc_e200(), which is one of
the two calling sites of register_BookE206_sprs(). This causes recent
versions of GCC to inline the register_BookE206_sprs() function into
the other only remaining calling site, init_proc_e500(), which in
turn causes some false-positives compiler warnings:
In file included from ../../devel/qemu/target/ppc/cpu_init.c:46:
In function ‘register_BookE206_sprs’,
inlined from ‘init_proc_e500’ at ../../devel/qemu/target/ppc/cpu_init.c:2910:5:
../../devel/qemu/target/ppc/cpu_init.c:897:29: error:
array subscript 3 is outside array bounds of ‘uint32_t[2]’ {aka ‘unsigned int[2]’}
[-Werror=array-bounds=]
897 | tlbncfg[3]);
| ~~~~~~~^~~
../../devel/qemu/target/ppc/spr_common.h:61:39: note: in definition of macro ‘spr_register_kvm_hv’
61 | KVM_ARG(one_reg_id) initial_value)
| ^~~~~~~~~~~~~
../../devel/qemu/target/ppc/spr_common.h:77:5: note: in expansion of macro ‘spr_register_kvm’
77 | spr_register_kvm(env, num, name, uea_read, uea_write, \
| ^~~~~~~~~~~~~~~~
../../devel/qemu/target/ppc/cpu_init.c:894:9: note: in expansion of macro ‘spr_register’
894 | spr_register(env, SPR_BOOKE_TLB3CFG, "TLB3CFG",
| ^~~~~~~~~~~~
../../devel/qemu/target/ppc/cpu_init.c: In function ‘init_proc_e500’:
../../devel/qemu/target/ppc/cpu_init.c:2809:14: note: at offset 12 into object ‘tlbncfg’ of size 8
2809 | uint32_t tlbncfg[2];
| ^~~~~~~
cc1: all warnings being treated as errors
init_proc_e500() only defines "uint32_t tlbncfg[2];", but it is OK since
it also sets "env->nb_ways = 2", so the code that GCC warns about in
register_BookE206_sprs() is never reached. Unfortunately, GCC is not smart
enough to see this, so it emits these warnings.
To fix it, let's simplify the code in register_BookE206_sprs() a little
bit to set up the SPRs in a loop, so we don't reference the tlbncfg[3]
entry directly anymore.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Chinmay Rath <rathc@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20251024065726.738005-2-thuth@redhat.com
Message-ID: <20251024065726.738005-2-thuth@redhat.com>
We recently introduced API for registering callbacks for trap related
events as well as the corresponding hook functions. Due to differences
between architectures, the latter need to be called from target specific
code.
This change places hooks for Power PC targets.
Signed-off-by: Julian Ganz <neither@nut.email>
Message-ID: <20251027110344.2289945-22-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
In gen_mcrfs() the FPSCR nibble mask is computed as:
`~((0xF << shift) & FP_EX_CLEAR_BITS)`
Here, 0xF is of type int, so the left shift is performed in
32-bit signed arithmetic. For bfa=0 we get shift=28,
and (0xF << 28) = 0xF0000000, which is not representable as a 32-bit
signed int. Static analyzers flag this as a potential integer
overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Sergeev <zeff@altlinux.org>
Reviewed-by: Chinmay Rath <rathc@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250915080118.29898-1-zeff@altlinux.org
Message-ID: <20250915080118.29898-1-zeff@altlinux.org>
QEMU has a way to deprecate CPUs by setting the 'deprecation_note' in
CPUClass.
Currently PowerPC CPUs don't use this deprecation process.
Introduce 'POWERPC_DEPRECATED_CPU' macro to deprecate particular PowerPC
CPUs in future.
With the change, QEMU will print a warning like below when the
deprecated CPU/Chips are used (example output if power8nvl is deprecated):
$ ./build/qemu-system-ppc64 -M powernv8 --cpu power8nvl -nographic
qemu-system-ppc64: warning: CPU model power8nvl_v1.0-powerpc64-cpu is deprecated -- CPU is unmaintained.
...
Also, print '(deprecated)' for deprecated CPUs in 'qemu-system-ppc64
--cpu ?' (example output if power8nvl is deprecated):
$ ./build/qemu-system-ppc64 --cpu help
...
power8e (alias for power8e_v2.1)
power8nvl_v1.0 PVR 004c0100 (deprecated)
power8nvl (alias for power8nvl_v1.0)
power8_v2.0 PVR 004d0200
...
Suggested-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250607110412.2342511-2-adityag@linux.ibm.com
Message-ID: <20250607110412.2342511-2-adityag@linux.ibm.com>
