qemu-devel.nongnu.org archive mirror
 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 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).