On 11.02.2013, at 16:13, 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 <da...@gibson.dropbear.id.au>
>> ---
>> 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.
Correct. The only thing he asked me about was the MMU bits. Removing those is
safe and a good idea. Having a full table of PVRs and aliases available is
still a good idea IMHO and we should preserve that.
Whether we're able to run such a CPU should be orthogonal information
(currently indicated by #ifdef TODO).
Alex
>
> 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?
>
> 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. :-)
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
