qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 14/50] target-ppc: make cpu-qom.h not target spe


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 14/50] target-ppc: make cpu-qom.h not target specific
Date: Tue, 17 May 2016 13:36:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1


On 17/05/2016 13:19, Thomas Huth wrote:
>> > +#if defined(TARGET_PPC64)
>> > +#define POWERPC_MMU_64       0x00010000
>> > +#define POWERPC_MMU_1TSEG    0x00020000
>> > +#define POWERPC_MMU_AMR      0x00040000
>> > +    /* 64 bits PowerPC MMU                                     */
>> > +    POWERPC_MMU_64B        = POWERPC_MMU_64 | 0x00000001,
>> > +    /* Architecture 2.03 and later (has LPCR) */
>> > +    POWERPC_MMU_2_03       = POWERPC_MMU_64 | 0x00000002,
>> > +    /* Architecture 2.06 variant                               */
>> > +    POWERPC_MMU_2_06       = POWERPC_MMU_64 | POWERPC_MMU_1TSEG
>> > +                             | POWERPC_MMU_AMR | 0x00000003,
>> > +    /* Architecture 2.06 "degraded" (no 1T segments)           */
>> > +    POWERPC_MMU_2_06a      = POWERPC_MMU_64 | POWERPC_MMU_AMR
>> > +                             | 0x00000003,
>> > +    /* Architecture 2.07 variant                               */
>> > +    POWERPC_MMU_2_07       = POWERPC_MMU_64 | POWERPC_MMU_1TSEG
>> > +                             | POWERPC_MMU_AMR | 0x00000004,
>> > +    /* Architecture 2.07 "degraded" (no 1T segments)           */
>> > +    POWERPC_MMU_2_07a      = POWERPC_MMU_64 | POWERPC_MMU_AMR
>> > +                             | 0x00000004,
>> > +#endif /* defined(TARGET_PPC64) */
>> > +};
> Moving code into cpu-qom.h that depends on a "#ifdef TARGET_PPC64"
> in a patch labeled "make cpu-qom.h not target specific" sounds somewhat
> wrong to me - even if it's only an enum... Could we somehow avoid this?

I would just remove the #ifdef here.  The TARGET_PPC64 in
PowerPPCCPUClass is a recipe for trouble.  If that field can be made
present unconditionally, that's probably a good idea.

Paolo



reply via email to

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