All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
Date: Mon, 31 Oct 2011 15:53:40 -0700	[thread overview]
Message-ID: <20111031225340.GC4078@us.ibm.com> (raw)
In-Reply-To: <20111031041412.GG9698@truffala.fritz.box>

On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
> Good points below.  I forgot to CC Nish, the original patch author on
> my post, so I've added him to the list now.
> 
> Nish, can you correct these problems and resend the patch please?

Yep, I'll work on this shortly.

> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
> > 
> > On 31.10.2011, at 04:16, David Gibson wrote:
> > 
> > > From: Nishanth Aravamudan <nacc@us.ibm.com>
> > > 
> > > When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> > > qemu monitor reports "dump_mmu: unimplemented".  However, during
> > > bringup work, it can be quite handy to have the SLB entries, which are
> > > available in the CPUPPCState.  This patch adds an implementation of
> > > info tlb for book3s, which dumps the SLB.
> > > 
> > > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > > target-ppc/helper.c |   32 +++++++++++++++++++++++++++-----
> > > 1 files changed, 27 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> > > index 137a494..29c7050 100644
> > > --- a/target-ppc/helper.c
> > > +++ b/target-ppc/helper.c
> > > @@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > >     }
> > > }
> > > 
> > > +static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> > > +                              CPUState *env)
> > > +{
> > > +    int i;
> > > +    uint64_t slbe, slbv;
> > > +
> > > +    cpu_synchronize_state(env);
> > > +
> > > +    cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
> > > +    for (i = 0; i < env->slb_nr; i++) {
> > > +        slbe = env->slb[i].esid;
> > > +        slbv = env->slb[i].vsid;
> > 
> > From cpu.h:
> > 
> > #if defined(TARGET_PPC64)
> >     /* Address space register */
> >     target_ulong asr;
> >     /* PowerPC 64 SLB area */
> >     ppc_slb_t slb[64];
> >     int slb_nr;
> > #endif

Being unfamiliar with qemu's coding style (and not immediately seeing it
in CODING_STYLE), would the right approach be to wrap this definition in
an #if defined(TARGET_PPC64)?

> > > +        if (slbe == 0 && slbv == 0) {
> > > +            continue;
> > > +        }
> > > +        cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
> > > +                    i, slbe, slbv);
> > > +    }
> > > +}
> > > +
> > > void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
> > > {
> > > -    switch (env->mmu_model) {
> > > -    case POWERPC_MMU_BOOKE206:
> > > +    if (env->mmu_model == POWERPC_MMU_BOOKE206) {
> > >         mmubooke206_dump_mmu(f, cpu_fprintf, env);
> > > -        break;
> > > -    default:
> > > -        cpu_fprintf(f, "%s: unimplemented\n", __func__);
> > > +    } else {
> > > +        if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
> > 
> > I would actually prefer to explicitly keep the switch and match on
> > all implementations explicitly. Also, have you verified this works
> > without CONFIG_PPC64 set? In cpu.h I see the following:
> > 
> > #if defined(TARGET_PPC64)
> > #define POWERPC_MMU_64       0x00010000
> > #define POWERPC_MMU_1TSEG    0x00020000
> >     /* 64 bits PowerPC MMU                                     */
> >     POWERPC_MMU_64B        = POWERPC_MMU_64 | 0x00000001,
> >     /* 620 variant (no segment exceptions)                     */
> >     POWERPC_MMU_620        = POWERPC_MMU_64 | 0x00000002,
> >     /* Architecture 2.06 variant                               */
> >     POWERPC_MMU_2_06       = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x00000003,
> > #endif /* defined(TARGET_PPC64) */
> > 
> > So POWERPC_MMU_64B shouldn't be defined for qemu-system-ppc.

And similarly here, only have the MMU_2_06 and MMU_64B cases in the
switch be defined #if defined(TARGET_PPC64)?

Basically, asking if #ifdefs in the middle of functions are ok :)

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

  reply	other threads:[~2011-10-31 22:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-31  3:16 [Qemu-devel] [0/3] Further ppc & pseries updates David Gibson
2011-10-31  3:16 ` [Qemu-devel] [PATCH 1/3] ppc: Alter CPU state to mask out TCG unimplemented instructions as appropriate David Gibson
2011-10-31  3:51   ` Alexander Graf
2011-10-31  3:16 ` [Qemu-devel] [PATCH 2/3] pseries: Add partial support for PCI David Gibson
2011-10-31  3:55   ` Alexander Graf
2011-10-31  3:16 ` [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries David Gibson
2011-10-31  3:35   ` Alexander Graf
2011-10-31  4:14     ` David Gibson
2011-10-31 22:53       ` Nishanth Aravamudan [this message]
2011-11-01  0:35         ` Alexander Graf
2011-11-01  1:18           ` Nishanth Aravamudan
2011-11-01 19:57       ` [Qemu-devel] [PATCH v2] " Nishanth Aravamudan
2011-11-10 17:11         ` Alexander Graf
2011-11-14  0:40           ` [Qemu-devel] [Qemu-ppc] " David Gibson
2011-11-14  6:25             ` Alexander Graf

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=20111031225340.GC4078@us.ibm.com \
    --to=nacc@us.ibm.com \
    --cc=agraf@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.