We added @error_warn some two years ago in commit 3ffef1a55c (error:
add global &error_warn destination). It has multiple issues:
* error.h's big comment was not updated for it.
* Function contracts were not updated for it.
* ERRP_GUARD() is unaware of @error_warn, and fails to mask it from
error_prepend() and such. These crash on @error_warn, as pointed
out by Akihiko Odaki.
All fixable. However, after more than two years, we had just of 15
uses, of which the last few patches removed seven as unclean or
otherwise undesirable, adding back five elsewhere. I didn't look
closely enough at the remaining seven to decide whether they are
desirable or not.
I don't think this feature earns its keep. Drop it.
Thanks-to: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20250923091000.3180122-14-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
ivshmem-flat's ivshmem_flat_add_vector() neglects to handle
qemu_set_blocking() failure. It used to silently ignore errors there.
Recent commit 6f607941b1 (treewide: use qemu_set_blocking instead of
g_unix_set_fd_nonblocking) changed it to warn (without mentioning it
the commit message, tsk, tsk, tsk).
Note that ivshmem-pci's process_msg_connect() handles this error.
Add a FIXME comment to mark the missing error handling.
Cc: Gustavo Romero <gustavo.romero@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250923091000.3180122-13-armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
We report d3d_texture2d_acquire0() and d3d_texture2d_release0()
failure as error, except in dbus_update_gl_cb(), where we report it as
warning. Report it as error there as well.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250923091000.3180122-12-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
From GLib "Rules for use of GError":
A GError* must be initialized to NULL before passing its address
to a function that can report errors.
dbus_update_gl_cb() seemingly violates this rule: it passes &err to
qemu_dbus_display1_listener_call_update_dmabuf_finish() and to
qemu_dbus_display1_listener_win32_d3d11_call_update_texture2d_finish()
without clearing it in between. Harmless, because the first call is
guarded by #ifdef CONFIG_GBM, the second by #ifdef WIN32, and the two
are mutually exclusive. I think.
Clean this up to be obviously correct.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250923091000.3180122-11-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
qemu_pixman_shareable_free() wraps around either qemu_memfd_free() or
qemu_win32_map_free(). The former reports trouble as error, with
error_report(), then succeeds. The latter reports it as warning (we
pass it &error_warn), then succeeds.
Change the latter to report as error, too.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250923091000.3180122-10-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
qemu_socket_select() and its wrapper qemu_socket_unselect() treat a
null @errp as &error_warn. This is wildly inappropriate. A caller
passing null @errp specifies that errors are to be ignored. If
warnings are wanted, the caller must pass &error_warn.
Change callers to do that, and drop the inappropriate treatment of
null @errp.
This assumes that warnings are wanted. I'm not familiar with the
calling code, so I can't say whether it will work when the socket is
invalid, or WSAEventSelect() fails. If it doesn't, then this should
be an error instead of a warning. Invalid socket might even be a
programming error.
These warnings were introduced in commit f5fd677ae7 (win32/socket:
introduce qemu_socket_select() helper). I considered reverting to
silence, but Daniel Berrangé asked for the warnings to be preserved.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250923091000.3180122-9-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
watch_add() reports _open_osfhandle() failure with
error_setg(&error_warn, ...). error_setg_win32(&error_warn, ...) is
undesirable just like error_setg(&error_fatal, ...) and
error_setg(&error_abort, ...) are. Replace by warn_report().
The failure should probably be an error, but this function implements
a callback that doesn't take Error **. I believe the failure will
make spice_server_init() fail in qemu_spice_init(), which is treated
as a fatal error. The warning here provides more detail than the
error message there.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250923091000.3180122-8-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
net_slirp_register_poll_sock() and net_slirp_unregister_poll_sock()
report WSAEventSelect() failure with error_setg(&error_warn, ...).
error_setg_win32(&error_warn, ...) is undesirable just like
error_setg(&error_fatal, ...) and error_setg(&error_abort, ...) are.
Replace by warn_report().
The failures should probably be errors, but these functions implement
callbacks that cannot fail, exit(1) would be too harsh, and silent
failure we don't want. Thus, warnings.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250923091000.3180122-7-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
VFU_OBJECT_ERROR() reports the error with error_setg(&error_abort,
...) when auto-shutdown is enabled, else with error_report().
Issues:
1. The error is serious enough to warrant aborting the process when
auto-shutdown is enabled, yet harmless enough to permit carrying on
when it's disabled. This makes no sense to me.
2. Like assert(), &error_abort is strictly for programming errors. Is
this one? Vladimir Sementsov-Ogievskiy tells me it's not. Should we
exit(1) instead?
3. qapi/error.h advises "don't error_setg(&error_abort, ...), use
assert()."
This patch addresses just 3. It adds a FIXME comment for the other
two.
Cc: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250923091000.3180122-6-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
[FIXME comment added, commit message adjusted accordingly]
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
qapi/error.h advises:
* Please don't error_setg(&error_fatal, ...), use error_report() and
* exit(), because that's more obvious.
Do that, and replace exit() by g_assert_not_reached(), since this is
actually a programming error.
Cc: Steve Sistare <steven.sistare@oracle.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Steve Sistare <steven.sistare@oracle.com>
Message-ID: <20250923091000.3180122-5-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Functions that use an Error **errp parameter to return errors should
not also report them to the user, because reporting is the caller's
job. When the caller does, the error is reported twice. When it
doesn't (because it recovered from the error), there is no error to
report, i.e. the report is bogus.
cxl_fmws_link_targets() violates this principle: it calls
error_setg(&error_fatal, ...) via cxl_fmws_link(). Goes back to
commit 584f722eb3 (hw/cxl: Make the CXL fixed memory windows
devices.) Currently harmless, because cxl_fmws_link_targets()'s
callers always pass &error_fatal. Clean this up by converting
cxl_fmws_link() to Error.
Also change its return value on error from 1 to -1 to conform to the
rules laid in qapi/error.h. It's call chain cxl_fmws_link_targets()
via object_child_foreach_recursive() is fine with that.
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250923091000.3180122-4-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
tcg_region_init() calls one of qemu_mprotect_rwx(),
qemu_mprotect_rw(), and mprotect(), then reports failure with
error_setg_errno(&error_fatal, errno, ...).
The use of &error_fatal is undesirable. qapi/error.h advises:
* Please don't error_setg(&error_fatal, ...), use error_report() and
* exit(), because that's more obvious.
The use of errno is wrong. qemu_mprotect_rwx() and qemu_mprotect_rw()
wrap around qemu_mprotect__osdep(). qemu_mprotect__osdep() calls
mprotect() on POSIX, VirtualProtect() on Windows, and reports failure
with error_report(). VirtualProtect() doesn't set errno. mprotect()
does, but error_report() may clobber it.
Fix tcg_region_init() to report errors only when it calls mprotect(),
and rely on qemu_mprotect_rwx()'s and qemu_mprotect_rw()'s error
reporting otherwise. Use error_report(), not error_setg().
Fixes: 22c6a9938f (tcg: Merge buffer protection and guard page protection)
Fixes: 6bc144237a (tcg: Use Error with alloc_code_gen_buffer)
Cc: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250923091000.3180122-3-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
HMP command gdbserver used to emit two error messages for certain
errors. For instance, with -M none:
(qemu) gdbserver
gdbstub: meaningless to attach gdb to a machine without any CPU.
Could not open gdbserver on device 'tcp::1234'
The first message is the specific error, and the second one a generic
additional message that feels superfluous to me.
Commit c0e6b8b798 (system: propagate Error to gdbserver_start (and
other device setups)) turned the first message into a warning:
warning: gdbstub: meaningless to attach gdb to a machine without any CPU.
Could not open gdbserver on device 'tcp::1234'
This is arguably worse.
hmp_gdbserver() passes &error_warn to gdbserver_start(), so that
failure gets reported as warning, and then additionally emits the
generic error on failure. This is a misuse of &error_warn.
Instead, receive the error in &err and report it, as usual. With
this, gdbserver reports just the error:
gdbstub: meaningless to attach gdb to a machine without any CPU.
Cc: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250923091000.3180122-2-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
* Support for PowerNV11 and PPE42 CPU/Machines.
* Deprecation of Power8E and Power8NVL
* Decodetree patches for some floating-point instructions
* Minor bug fixes, improvements in ppc/spapr/xive/xics.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEa4EM1tK+EPOIPSFCRUTplPnWj7sFAmjZgYQACgkQRUTplPnW
j7uNJQ/8Cbr3xqyCyyqL+MM+Ze1PbXe4xSgdg13A1sNU3IHTffB77DCQVOxjudUS
uo+XHVFssc4SKDZYjEzXFnYpzRpbZzfcuhG4kgn9QQ3VyKP+2xe6kWLleDbB6ds1
e9ZAW6Ryk4R3ZFLnZzGfEdltliaoIn6zy4R25oJfJUgIRt0Xz++GBxll+Tdr8Exy
qstvvyyjeTiIS3kA1zk6fbhDRJKKBsA0L1G1Pk6AuTMKa1RRTCniA36idnGVFAuY
ef8WCEQYQS0do9Ytai06Tp1QNRVMG2y+AsKbSQRMi92lFfn+qhvA29OJd5TNvXtp
LNiIfXHo3jLjGBUP13iVN8b8udWdis9BayvA/OwDaKWgononEHb9nqJgzVJR4n7t
DxxUxcSCiEXOpObtklrKhi1nDt16nXPZ/bnnreMSWzxHBZK1My7qnI3S0hA7c11z
YgssB5wJbRaETaEVzQfWfAcSaPpXBzBEXOAJcbd+Ni6w9SxXz2OrhckTOvfrXpmI
XQ1KFUCkmTtXF1qB+oEihlrvG2qjdGuleRZdyiktaM2psBFgN/2gHl3S+JjL9kiY
9FdBffr/2K604l7EQkAYWixe2WMMsjHVHpuxJ7opG7MMSXJZq9cXKIK+tbkSNoRO
Ia6Qr6eWJWjFF3y4OZCbYAOVU77ez6lo7kRj0e99fOjxfI+UuWU=
=Fjdq
-----END PGP SIGNATURE-----
Merge tag 'pull-ppc-for-20250928-20250929' of https://gitlab.com/harshpb/qemu into staging
ppc queue for 20250928
* Support for PowerNV11 and PPE42 CPU/Machines.
* Deprecation of Power8E and Power8NVL
* Decodetree patches for some floating-point instructions
* Minor bug fixes, improvements in ppc/spapr/xive/xics.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEa4EM1tK+EPOIPSFCRUTplPnWj7sFAmjZgYQACgkQRUTplPnW
# j7uNJQ/8Cbr3xqyCyyqL+MM+Ze1PbXe4xSgdg13A1sNU3IHTffB77DCQVOxjudUS
# uo+XHVFssc4SKDZYjEzXFnYpzRpbZzfcuhG4kgn9QQ3VyKP+2xe6kWLleDbB6ds1
# e9ZAW6Ryk4R3ZFLnZzGfEdltliaoIn6zy4R25oJfJUgIRt0Xz++GBxll+Tdr8Exy
# qstvvyyjeTiIS3kA1zk6fbhDRJKKBsA0L1G1Pk6AuTMKa1RRTCniA36idnGVFAuY
# ef8WCEQYQS0do9Ytai06Tp1QNRVMG2y+AsKbSQRMi92lFfn+qhvA29OJd5TNvXtp
# LNiIfXHo3jLjGBUP13iVN8b8udWdis9BayvA/OwDaKWgononEHb9nqJgzVJR4n7t
# DxxUxcSCiEXOpObtklrKhi1nDt16nXPZ/bnnreMSWzxHBZK1My7qnI3S0hA7c11z
# YgssB5wJbRaETaEVzQfWfAcSaPpXBzBEXOAJcbd+Ni6w9SxXz2OrhckTOvfrXpmI
# XQ1KFUCkmTtXF1qB+oEihlrvG2qjdGuleRZdyiktaM2psBFgN/2gHl3S+JjL9kiY
# 9FdBffr/2K604l7EQkAYWixe2WMMsjHVHpuxJ7opG7MMSXJZq9cXKIK+tbkSNoRO
# Ia6Qr6eWJWjFF3y4OZCbYAOVU77ez6lo7kRj0e99fOjxfI+UuWU=
# =Fjdq
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 28 Sep 2025 11:42:12 AM PDT
# 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-20250928-20250929' of https://gitlab.com/harshpb/qemu: (27 commits)
target/ppc: use MAKE_64BIT_MASK for mcrfs exception clear mask
target/ppc: Deprecate Power8E and Power8NVL
target/ppc: Introduce macro for deprecating PowerPC CPUs
target/ppc: Move remaining floating-point move instructions to decodetree.
target/ppc: Move floating-point move instructions to decodetree.
target/ppc: Move floating-point compare instructions to decodetree.
target/ppc: Move floating-point rounding and conversion instructions to decodetree.
ppc/xive2: Fix integer overflow warning in xive2_redistribute()
ppc/spapr: init lrdr-capapcity phys with ram size if maxmem not provided
hw/intc/xics: Add missing call to register vmstate_icp_server
tests/functional: Add test for IBM PPE42 instructions
hw/ppc: Add a test machine for the IBM PPE42 CPU
hw/ppc: Support for an IBM PPE42 CPU decrementer
target/ppc: Add IBM PPE42 special instructions
target/ppc: Support for IBM PPE42 MMU
target/ppc: Add IBM PPE42 exception model
target/ppc: IBM PPE42 exception flags and regs
target/ppc: Add IBM PPE42 family of processors
target/ppc: IBM PPE42 general regs and flags
tests/powernv: Add PowerNV test for Power11
...
Signed-off-by: Richard Henderson <richard.henderson@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>
Power8E and Power8NVL variants are not of much use in QEMU now, and not
being maintained either.
Power8NVL CPU doesn't boot since skiboot v7.0, or following skiboot commit
to be exact:
commit c5424f683ee3 ("Remove support for POWER8 DD1")
Deprecate the 8E and 8NVL variants.
Suggested-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
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-3-adityag@linux.ibm.com
Message-ID: <20250607110412.2342511-3-adityag@linux.ibm.com>
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>
Move below instructions to decodetree specification:
fcpsgn, fmrg{e, o}w : X-form
The changes were verified by validating that the tcg ops generated by
those instructions remain the same, which were captured with the '-d
in_asm,op' flag.
Signed-off-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250619095840.369351-5-rathc@linux.ibm.com
Message-ID: <20250619095840.369351-5-rathc@linux.ibm.com>
Move below instructions to decodetree specification:
f{mr, neg, abs, nabs} : X-form
The changes were verified by validating that the tcg ops generated by
those instructions remain the same, which were captured with the '-d
in_asm,op' flag.
Signed-off-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250619095840.369351-4-rathc@linux.ibm.com
Message-ID: <20250619095840.369351-4-rathc@linux.ibm.com>
Move below instructions to decodetree specification :
fcmp{u, o} : X-form
The changes were verified by validating that the tcg ops generated by
those instructions remain the same, which were captured with the '-d
in_asm,op' flag.
Signed-off-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250619095840.369351-3-rathc@linux.ibm.com
Message-ID: <20250619095840.369351-3-rathc@linux.ibm.com>
Move below instructions to decodetree specification :
fr{sp, in, iz, im}[s][.],
fcti{w, d}[u, z, uz][s][.],
fcfid[s, u, us][s][.] : X-form
The changes were verified by validating that the tcg ops generated by
those instructions remain the same, which were captured with the '-d
in_asm,op' flag.
Signed-off-by: Chinmay Rath <rathc@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250619095840.369351-2-rathc@linux.ibm.com
Message-ID: <20250619095840.369351-2-rathc@linux.ibm.com>
Coverity reported an integer overflow warning in xive2_redistribute()
where the code does a left shift operation "0xffffffff << crowd". Fix the
warning by using a 64 byte integer type. Also refactor the calculation
into dedicated routines.
Resolves: Coverity CID 1612608
Fixes: 555e446019 ("ppc/xive2: Support redistribution of group interrupts")
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250811074912.162774-1-gautam@linux.ibm.com
Message-ID: <20250811074912.162774-1-gautam@linux.ibm.com>
lrdr-capacity contains phys field which communicates the maximum address
in bytes and therefore, the most memory that can be allocated to this
partition. This is usually populated when maxmem is provided alongwith
memory size on qemu command line. However since maxmem is an optional
param, this leads to bits being set to 0 in absence of maxmem param.
Fix this by initializing the respective bits as per total mem size in
such case.
Reported-by: Gaurav Batra <gbatra@us.ibm.com>
Tested-by: David Christensen <drc@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Reviewed-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Link: https://lore.kernel.org/r/20250506042903.76250-1-harshpb@linux.ibm.com
Message-ID: <20250506042903.76250-1-harshpb@linux.ibm.com>
An obsolete wrapper function with a workaround was removed entirely,
without restoring the call it wrapped.
Without this, the guest is stuck after savevm/loadvm.
Fixes: 24ee9229fe ("ppc/spapr: remove deprecated machine pseries-2.9")
Signed-off-by: Fabian Vogt <fvogt@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/6187781.lOV4Wx5bFT@fvogt-thinkpad
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250819223905.2247-2-farosas@suse.de
Message-ID: <20250819223905.2247-2-farosas@suse.de>
Adds a functional test for the IBM PPE42 instructions which
downloads a test image from a public github repo and then
loads and executes the image.
(see https://github.com/milesg-github/ppe42-tests for details)
Test status is checked by periodically issuing 'info register'
commands and checking the NIP value. If the NIP is 0xFFF80200
then the test successfully executed to completion. If the
machine stops before the test completes or if a 90 second
timeout is reached, then the test is marked as having failed.
This test does not test any PowerPC instructions as it is
expected that these instructions are well covered in other
tests. Only instructions that are unique to the IBM PPE42
processor are tested.
Signed-off-by: Glenn Miles <milesg@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925201758.652077-10-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-10-milesg@linux.ibm.com>
Adds a test machine for the IBM PPE42 processor, including a
DEC, FIT, WDT and 512 KiB of ram.
The purpose of this machine is only to provide a generic platform
for testing instructions of the recently added PPE42 processor
model which is used extensively in the IBM Power9, Power10 and
future Power server processors.
Signed-off-by: Glenn Miles <milesg@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925201758.652077-9-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-9-milesg@linux.ibm.com>
The IBM PPE42 processors support a 32-bit decrementer
that can raise an external interrupt when DEC[0]
transitions from a 0 to a -1 (a non-negative value to a
negative value). It also continues decrementing
even after this condition is met.
The BookE timer is slightly different in that it
raises an interrupt when the DEC value reaches 0
and stops decrementing at that point.
Support a PPE42 version of the BookE timer by
adding a new PPC_TIMER_PPE flag that has the timer
code look for the transition from a non-negative value
to a negative value and allows the value to
continue decrementing.
Signed-off-by: Glenn Miles <milesg@linux.ibm.com>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925201758.652077-8-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-8-milesg@linux.ibm.com>
The IBM PPE42 processor only supports real mode
addressing and does not distinguish between
problem and supervisor states. It also uses
the IR and DR MSR bits for other purposes.
Therefore, add a check for PPE42 when we update
hflags and cause it to ignore the IR and DR bits
when calculating MMU indexes.
Signed-off-by: Glenn Miles <milesg@linux.ibm.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/20250925201758.652077-6-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-6-milesg@linux.ibm.com>
Add support for the IBM PPE42 exception model including
new exception vectors, exception priorities and setting
of PPE42 SPRs for determining the cause of an exception.
Signed-off-by: Glenn Miles <milesg@linux.ibm.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/20250925201758.652077-5-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-5-milesg@linux.ibm.com>
Introduces flags and register definitions needed
for the IBM PPE42 exception model.
Signed-off-by: Glenn Miles <milesg@linux.ibm.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/20250925201758.652077-4-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-4-milesg@linux.ibm.com>
Adds the IBM PPE42 family of 32-bit processors supporting
the PPE42, PPE42X and PPE42XM processor versions. These
processors are used as embedded processors in the IBM
Power9, Power10 and Power12 processors for various
tasks. It is basically a stripped down version of the
IBM PowerPC 405 processor, with some added instructions
for handling 64-bit loads and stores.
For more information on the PPE 42 processor please visit:
https://wiki.raptorcs.com/w/images/a/a3/PPE_42X_Core_Users_Manual.pdf
Supports PPE42 SPR's (Including the MSR).
Does not yet support exceptions, new PPE42 instructions and
does not prevent access to some invalid instructions and
registers (currently allows access to invalid GPR's and CR
fields).
Signed-off-by: Glenn Miles <milesg@linux.ibm.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/20250925201758.652077-3-milesg@linux.ibm.com
Message-ID: <20250925201758.652077-3-milesg@linux.ibm.com>
With all Power11 support in place, add Power11 PowerNV test.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-9-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-9-adityag@linux.ibm.com>
As op-build images haven't been updated from long time (and may not get
updated in future), use buildroot images provided by cedric [1].
Use existing nvme device being used in the test to mount the initrd.
Also replace the check for "zImage loaded message" to skiboot's message
when it starts the kernel: "Starting kernel at", since we are no longer
using zImage from op-build
This is required for newer processor tests such as Power11, as the
op-build kernel image is old and doesn't support Power11.
Power11 test has been added in a later patch.
[1]: https://github.com/legoater/qemu-ppc-boot/tree/main/buildroot/qemu_ppc64le_powernv8-2025.02
Suggested-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-8-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-8-adityag@linux.ibm.com>
Introduce Power11 ChipTod. The code has been copied from Power10 ChipTod
code as the Power11 core is same as Power10 core.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-7-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-7-adityag@linux.ibm.com>
Power11 also uses PHB5, same as Power10.
Add Power11 PHBs with similar code as the corresponding Power10 implementation.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-6-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-6-adityag@linux.ibm.com>
Add a XIVE2 controller to Power11 chip and machine.
The controller has the same logic as Power10.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-5-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-5-adityag@linux.ibm.com>
Existing code in XIVE2 assumes the chip to be a Power10 Chip.
Instead add a handler to get reference to the interrupt controller (XIVE)
for a given Power Chip.
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-4-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-4-adityag@linux.ibm.com>
The Powernv11 machine doesn't have XIVE & PHBs as of now
XIVE2 interface and PHB5 added in later patches to Powernv11 machine
Also add mention of Power11 to powernv documentation
Note: A difference from P10's and P11's machine_class_init is, in P11
different number of PHBs cannot be used on the command line, ie. the
following line does NOT exist in pnv_machine_power11_class_init, which
existed in case of Power10:
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-3-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-3-adityag@linux.ibm.com>
Implement Pnv11Chip, currently without chiptod, xive and phb.
Chiptod, XIVE, PHB are implemented in later patches.
Since Power11 core is same as Power10, the implementation of Pnv11Chip
is a duplicate of corresponding Pnv10Chip.
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Link: https://lore.kernel.org/r/20250925173049.891406-2-adityag@linux.ibm.com
Message-ID: <20250925173049.891406-2-adityag@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCaNjtuwAKCRAfewwSUazn
0Z9VAQDuqEzBEj0I3L7AtJgwRxSau+sw9FqUdAjQguM9mA29ggD7BOBFwHpjx68t
8MMstQuZN2mFRwzfukIdLDZclPCKkAM=
=L9oL
-----END PGP SIGNATURE-----
Merge tag 'pull-loongarch-20250928' of https://github.com/bibo-mao/qemu into staging
loongarch queue
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCaNjtuwAKCRAfewwSUazn
# 0Z9VAQDuqEzBEj0I3L7AtJgwRxSau+sw9FqUdAjQguM9mA29ggD7BOBFwHpjx68t
# 8MMstQuZN2mFRwzfukIdLDZclPCKkAM=
# =L9oL
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 28 Sep 2025 01:11:39 AM PDT
# 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-20250928' of https://github.com/bibo-mao/qemu:
target/loongarch: Only flush one TLB entry in helper_invtlb_page_asid()
target/loongarch: Only flush one TLB entry in helper_invtlb_page_asid_or_g()
target/loongarch: Invalid tlb entry in invalidate_tlb()
target/loongarch: Use loongarch_tlb_search_cb in helper_invtlb_page_asid
target/loongarch: Use loongarch_tlb_search_cb in helper_invtlb_page_asid_or_g
target/loongarch: Change return value type with loongarch_tlb_search_cb()
target/loongarch: Add common API loongarch_tlb_search_cb()
target/loongarch: Add tlb search callback in loongarch_tlb_search()
target/loongarch: Fix page size set issue with CSR_STLBPS
target/loongarch: Update TLB index selection method
target/loongarch: Reduce TLB flush with helper_tlbwr
target/loongarch: Add parameter tlb pointer with fill_tlb_entry
target/loongarch: Use mmu idx bitmap method when flush TLB
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
when cpu added, connect dintc irq to cpu INT_DMSI irq pin.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250916122109.749813-12-gaosong@loongson.cn>
implement the read-clear feature for CSR_MSGIR register.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250916122109.749813-11-gaosong@loongson.cn>
Add CSR_ESTAT.bit15 and CSR_ECFG.bit15 for DINTC irq.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250916122109.749813-10-gaosong@loongson.cn>
Implement dintc set irq and update CSR_MSGIS.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250916122109.749813-9-gaosong@loongson.cn>
the DINTC use [2fe00000-2ff00000) Memory.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-ID: <20250916122109.749813-7-gaosong@loongson.cn>
include CSR_MSGIS0-3, CSR_MSGIR and CSR_MSGIE.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250916122109.749813-6-gaosong@loongson.cn>
