qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7
Date: Wed, 21 May 2014 15:23:59 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0


On 21.05.14 14:30, Alexey Kardashevskiy wrote:
On 05/21/2014 08:44 PM, Alexander Graf wrote:
On 21.05.14 08:20, Alexey Kardashevskiy wrote:
This moves SPR initialization to helper functions.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
I like the idea, but please refactor all book3s CPUs, not just POWER7.

I also think we can cover a lot of the SPR registration by matching on
feature fields. VR for example is coupled to Altivec.

Ok.

Maybe we could also introduce an enum for the exact cpu type, similar to
how we do it on e500? Then we could do fun things like

if (cpu_type >= CPU_TYPE_970) {
     gen_spr_book3s_vr(env);
}

if (cpu_type >= CPU_TYPE_POWER7) {
     gen_spr_lpar(env);
}

switch (cpu_type) {
     case CPU_TYPE_POWER7:
         env->slb_nr = 32;
         break;
     default:
         env->slb_nr = 64;
         break;
}

and thus combine all those book3s init functions into a single, more
maintainable version.
If I can, I would like not to do it in this way, I'd rather have explicit
list of gen_spr_FACILITY() calls always. For example,
DABR/DABRX/whateverPOWER8has - it is not going to be always ">", and this
breaks my weak mind :(

Could you give me some examples where a newer POWER has lost features over an older POWER?


Alex




reply via email to

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