qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH] (RFC) target-ppc: Remove vestigial P


From: David Gibson
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] (RFC) target-ppc: Remove vestigial PowerPC 620 support
Date: Tue, 12 Feb 2013 10:25:55 +1100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Feb 11, 2013 at 04:13:58PM +0100, Andreas Färber wrote:
> Am 11.02.2013 05:50, schrieb David Gibson:
> > The PowerPC 620 was the very first 64-bit PowerPC implementation, but
> > hardly anyone ever actually used the chips.  qemu notionally supports the
> > 620, but since we don't actually have code to implement the segment table,
> > the support is broken (quite likely in other ways too).
> > 
> > This partch, therefore, removes all remaining pieces of 620 support, to
> > stop it cluttering up the platforms we actually care about.
> > 
> > Signed-off-by: David Gibson <address@hidden>
> > ---
> >  monitor.c                   |    4 -
> >  target-ppc/cpu.h            |   29 -----
> >  target-ppc/helper.h         |    1 -
> >  target-ppc/machine.c        |    4 +-
> >  target-ppc/misc_helper.c    |    6 --
> >  target-ppc/mmu_helper.c     |   44 +-------
> >  target-ppc/translate.c      |    1 -
> >  target-ppc/translate_init.c |  251 
> > -------------------------------------------
> >  8 files changed, 7 insertions(+), 333 deletions(-)
> > 
> > Andreas,
> > 
> > I know Alex Graf is happy to remove the PPC620 stuff, but he suggested
> > I talk to you since prep is the only existing ppc machine which would
> > ever have supported a PPC620 CPU.  Any objections?
> [...]
> > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> > index f038850..7dc1b9b 100644
> > --- a/target-ppc/translate_init.c
> > +++ b/target-ppc/translate_init.c
> [...]
> > @@ -9244,10 +9000,6 @@ static const ppc_def_t ppc_defs[] = {
> >      POWERPC_DEF("7457A_v1.2",    CPU_POWERPC_74x7A_v12,              7455),
> >      /* 64 bits PowerPC                                                     
> >   */
> >  #if defined (TARGET_PPC64)
> > -    /* PowerPC 620                                                         
> >   */
> > -    POWERPC_DEF("620",           CPU_POWERPC_620,                    620),
> > -    /* Code name for PowerPC 620                                           
> >   */
> > -    POWERPC_DEF("Trident",       CPU_POWERPC_620,                    620),
> >  #if defined (TODO)
> >      /* PowerPC 630 (POWER3)                                                
> >   */
> >      POWERPC_DEF("630",           CPU_POWERPC_630,                    630),
> [snip]
> 
> Are you sure this is what Alex asked you to do? Because he specifically
> instructed me NOT to remove any of these model definitions or their PVR
> values, even if guarded by defined(TODO), about a week ago.

Oh, yes, oops.  I realised I shouldn't remove the PVR, but I'll update
the patch to leave these defs in place, too.

> I'll polish what I have cooking for the CPU models later today; the MMU
> code itself has not been touched by my refactorings so far.
> We do have a conflict here in that I have moved all code name aliases
> from the above definitions array to another array (here: "Trident").
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-ppc-types (WIP)
> 
> We were hoping to refactor the current macro mess into a set of
> self-contained abstract parent classes, and I was hoping that we might
> be able to move them out of translate_init.c afterwards, to speed up
> compilation.
> Would isolating 620 code in a, say, cpu-620.c help you or is this about
> some ifs in disas or whatever code? Or what exactly is your motivation?

That wouldn't really help, the 620 references are too scattered.  The
motivation is that I'm looking at doing a substantial cleanup to the
MMU code.  Specifically I plan to disentable the paths for 64-bit hash
"classic" MMU from the current overly general paths, then start
cleaning that path up.  620 is the only (kinda sorta) supported
segment table CPU present.  I don't really want to implement segment
table lookup, and it seems kind of stupid to re-implement the current
broken support.

> The BeBox had a 604e iirc and so far all my PReP testing has been
> 32-bit. CC'ing Hervé on whether any of his 40P emulations need the 620.
> 
> Regards,
> Andreas
> 
> P.S. Still waiting on your feedback on sPAPR hypercall testing and CPU
> hot-plug btw. :-)

Uh.. I seem to have missed that one somehow.  What subject line should
I search for?

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]