[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-ppc] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7 |
Date: |
Wed, 21 May 2014 22:30:47 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 |
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 :(
--
Alexey
- [Qemu-ppc] [PATCH 1/9] target-ppc: Rename MMCR0/1 contants, (continued)
[Qemu-ppc] [PATCH 4/9] target-ppc: Refactor init_proc_POWER8, Alexey Kardashevskiy, 2014/05/21
[Qemu-ppc] [PATCH 8/9] spapr_hcall: Split h_set_mode(), Alexey Kardashevskiy, 2014/05/21
[Qemu-ppc] [PATCH 6/9] target-ppc: Enable PPR and VRSAVE SPRs migration, Alexey Kardashevskiy, 2014/05/21
[Qemu-ppc] [PATCH 7/9] KVM: target-ppc: Enable transactional state migration, Alexey Kardashevskiy, 2014/05/21