From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: qemu-devel@nongnu.org
Cc: Thomas Huth <thuth@redhat.com>, Chinmay Rath <rathc@linux.ibm.com>
Subject: [PULL 03/10] target/ppc/cpu_init: Simplify the setup of the TLBxCFG SPR registers
Date: Thu, 30 Oct 2025 14:19:29 +0530 [thread overview]
Message-ID: <20251030084936.1132417-4-harshpb@linux.ibm.com> (raw)
In-Reply-To: <20251030084936.1132417-1-harshpb@linux.ibm.com>
From: Thomas Huth <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>
---
target/ppc/cpu_init.c | 38 ++++++++++++--------------------------
1 file changed, 12 insertions(+), 26 deletions(-)
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 3aa3aefc13..12c645699e 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -850,6 +850,13 @@ static void register_BookE206_sprs(CPUPPCState *env, uint32_t mas_mask,
SPR_BOOKE_MAS0, SPR_BOOKE_MAS1, SPR_BOOKE_MAS2, SPR_BOOKE_MAS3,
SPR_BOOKE_MAS4, SPR_BOOKE_MAS5, SPR_BOOKE_MAS6, SPR_BOOKE_MAS7,
};
+ const char *tlbcfg_names[4] = {
+ "TLB0CFG", "TLB1CFG", "TLB2CFG", "TLB3CFG",
+ };
+ const int tlbcfg_sprn[4] = {
+ SPR_BOOKE_TLB0CFG, SPR_BOOKE_TLB1CFG,
+ SPR_BOOKE_TLB2CFG, SPR_BOOKE_TLB3CFG,
+ };
int i;
/* TLB assist registers */
@@ -889,34 +896,13 @@ static void register_BookE206_sprs(CPUPPCState *env, uint32_t mas_mask,
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, SPR_NOACCESS,
mmucfg);
- switch (env->nb_ways) {
- case 4:
- spr_register(env, SPR_BOOKE_TLB3CFG, "TLB3CFG",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, SPR_NOACCESS,
- tlbncfg[3]);
- /* Fallthru */
- case 3:
- spr_register(env, SPR_BOOKE_TLB2CFG, "TLB2CFG",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, SPR_NOACCESS,
- tlbncfg[2]);
- /* Fallthru */
- case 2:
- spr_register(env, SPR_BOOKE_TLB1CFG, "TLB1CFG",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, SPR_NOACCESS,
- tlbncfg[1]);
- /* Fallthru */
- case 1:
- spr_register(env, SPR_BOOKE_TLB0CFG, "TLB0CFG",
+
+ assert(env->nb_ways <= ARRAY_SIZE(tlbcfg_names));
+ for (i = 0; i < env->nb_ways; i++) {
+ spr_register(env, tlbcfg_sprn[i], tlbcfg_names[i],
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, SPR_NOACCESS,
- tlbncfg[0]);
- /* Fallthru */
- case 0:
- default:
- break;
+ tlbncfg[i]);
}
#endif
}
--
2.43.5
next prev parent reply other threads:[~2025-10-30 8:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 8:49 [PULL 00/10] ppc-for-10.2-d4 queue Harsh Prateek Bora
2025-10-30 8:49 ` Harsh Prateek Bora [this message]
2025-10-30 8:49 ` [PULL 04/10] target/ppc: Remove the unusable e200 CPUs Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 05/10] ppc/spapr: Cleanup MSI IRQ number handling Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 06/10] hw/ppc: Fix missing return on allocation failure Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 07/10] hw/ppc: Fix memory leak in get_cpu_state_data() Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 08/10] hw/ppc/pegasos2: Add /chosen/stdin node with VOF Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 09/10] hw/ppc/pegasos2: Rename to pegasos Harsh Prateek Bora
2025-10-30 8:49 ` [PULL 10/10] hw/ppc/pegasos: Update documentation for pegasos1 Harsh Prateek Bora
2025-11-01 9:50 ` [PULL 00/10] ppc-for-10.2-d4 queue Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251030084936.1132417-4-harshpb@linux.ibm.com \
--to=harshpb@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=rathc@linux.ibm.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).