qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Nicholas Piggin" <npiggin@gmail.com>
To: "BALATON Zoltan" <balaton@eik.bme.hu>
Cc: <qemu-ppc@nongnu.org>, <qemu-devel@nongnu.org>,
	"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Anushree Mathur" <anushree.mathur@linux.vnet.ibm.com>,
	"Fabiano Rosas" <farosas@suse.de>
Subject: Re: [PATCH 1/4] target/ppc: Fix instruction loading endianness in alignment interrupt
Date: Wed, 21 Jun 2023 02:54:47 +1000	[thread overview]
Message-ID: <CTHMVFHEA2B4.3968LCTW14GHR@wheely> (raw)
In-Reply-To: <393305f2-e785-c3f6-523f-6826b3511cc4@eik.bme.hu>

On Wed Jun 21, 2023 at 12:26 AM AEST, BALATON Zoltan wrote:
> On Tue, 20 Jun 2023, Nicholas Piggin wrote:
> > powerpc ifetch endianness depends on MSR[LE] so it has to byteswap
> > after cpu_ldl_code(). This corrects DSISR bits in alignment
> > interrupts when running in little endian mode.
> >
> > Reviewed-by: Fabiano Rosas <farosas@suse.de>
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > target/ppc/excp_helper.c | 22 +++++++++++++++++++++-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> > index 12d8a7257b..a2801f6e6b 100644
> > --- a/target/ppc/excp_helper.c
> > +++ b/target/ppc/excp_helper.c
> > @@ -133,6 +133,26 @@ static void dump_hcall(CPUPPCState *env)
> >                   env->nip);
> > }
> >
> > +#ifdef CONFIG_TCG
> > +/* Return true iff byteswap is needed to load instruction */
> > +static inline bool insn_need_byteswap(CPUArchState *env)
> > +{
> > +    /* SYSTEM builds TARGET_BIG_ENDIAN. Need to swap when MSR[LE] is set */
> > +    return !!(env->msr & ((target_ulong)1 << MSR_LE));
> > +}
>
> Don't other places typically use FIELD_EX64 to test for msr bits now? If 

Yeah I should use that, good point. There's at least another case in
that file that doesn't use it but I probably added that too :/

> this really only tests for the LE bit and used only once do we need a new 
> function for that? I don't quite like trivial one line functions unless it 
> does something more complex Because if just makes code harder to read as I 
> have to look up what these do when I could just see it right away where it 
> used without these functions.

It's based on mem_helper.c, which is familiar pattern/name so I 
might keep it. Maybe not, I'll check. I'm on the fence.

> > +
> > +static uint32_t ppc_ldl_code(CPUArchState *env, hwaddr addr)
> > +{
> > +    uint32_t insn = cpu_ldl_code(env, addr);
> > +
> > +    if (insn_need_byteswap(env)) {
> > +        insn = bswap32(insn);
> > +    }
> > +
> > +    return insn;
> > +}
> > +#endif
>
> Along the same lines I'm not sure this wrapper is needed unless this is a 
> recurring operation. Otherwise you could just add the if and the comment 
> below at the single place where this is needed. If this will be needed at 
> more places later then adding a function may make sense but otherwise I'd 
> avoid making code tangled with single line functions defined away from 
> where they are used as it's simpler to just have the if and swap at the 
> single place where it's needed than adding two new functions that I'd had 
> to look up and comprehend first to see what's happening. (It also would be 
> just 3 lines instead of 20 that way.)

It does get used in a couple more places later. Few-line
"abstraction" used once isn't necessarily wrong though.

Thanks,
Nick


  reply	other threads:[~2023-06-20 16:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 13:10 [PATCH 0/4] target/ppc: Fixes for instruction-related Nicholas Piggin
2023-06-20 13:10 ` [PATCH 1/4] target/ppc: Fix instruction loading endianness in alignment interrupt Nicholas Piggin
2023-06-20 14:26   ` BALATON Zoltan
2023-06-20 16:54     ` Nicholas Piggin [this message]
2023-06-21  5:41       ` Nicholas Piggin
2023-06-20 13:10 ` [PATCH 2/4] target/ppc: Change partition-scope translate interface Nicholas Piggin
2023-06-20 13:10 ` [PATCH 3/4] target/ppc: Add SRR1 prefix indication to interrupt handlers Nicholas Piggin
2023-06-20 13:10 ` [PATCH 4/4] target/ppc: Implement HEIR SPR Nicholas Piggin
2023-06-23  9:31 ` [PATCH 0/4] target/ppc: Fixes for instruction-related Cédric Le Goater
2023-06-28  5:56 ` Anushree Mathur

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=CTHMVFHEA2B4.3968LCTW14GHR@wheely \
    --to=npiggin@gmail.com \
    --cc=anushree.mathur@linux.vnet.ibm.com \
    --cc=balaton@eik.bme.hu \
    --cc=danielhb413@gmail.com \
    --cc=farosas@suse.de \
    --cc=harshpb@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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).