Re: [Qemu-devel] Removal of some target CPU macros

[Fabrice Bellard <fabrice@bellard.org>]

J. Mayer wrote:
> On Wed, 2007-11-07 at 22:55 +0100, Fabrice Bellard wrote:
>> Jocelyn Mayer wrote:
>>> On Wed, 2007-11-07 at 19:32 +0100, Fabrice Bellard wrote:
>>>> I noticed that some target CPUs macros have been added while they do not
>>>> seem necessary. I don't like that because it introduces more #ifdefs
>>>> which prevent making a version supporting simultaneously all the CPUs.
>>>>
>>>> In particular I saw the following:
>>>>
>>>> - TARGET_MIPSN32 : it is always combined with TARGET_MIPS64 in
>>>> target-mips/. If its only usage is to select a different Linux ABI, then
>>>> I suggest keeping TARGET_MIPS64 and using another define to choose that.
>>>>
>>>> - TARGET_PPC64H, TARGET_PPCEMB : I see no reason why they cannot be
>>>> handled dynamically as the other PowerPC CPU types, provided that
>>>> TARGET_PPC64 is defined. Is it the long term plan ?
>>> PowerPC embedded models are already available (should say should be as
>>> none are actually implemented) when PPC64 is defined. But as those are
>>> mainly PowerPC 32 with some extensions to manipulate the 64 bits GPR,
>>> it's a great help if we can avoid doing all operations in 64 bits when
>>> running on a 32 bits host (which would greatly decrease performances by
>>> at least a factor of two, which is not acceptable). Then having a
>>> specific 32 bits target using 64 bits register is very useful if one
>>> want to use those features, but may be disabled if the host is 64 bits.
>>> Note that most (all ?) embedded Freescale PowerPC microcontrollers
>>> implement those extensions and that some ones are greatly interrested
>>> with having an usable emulation avaible for those CPUs.
>> OK for the speed gain, but such features make the code more difficult to
>> test because there are a lot of possible combinations. I'd say the same
>> about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU.
> 
> I got no choice here, as the 64 bits extensions of those CPUs uses the
> GPR for computations. And the programs are supposed not to take any care
> of the higher 32 bits when not using those extensions. I cannot make
> them 64 bits for all PowerPC targets and those CPU are not PowerPC 64
> ones, so they do not match neither the PowerPC target, neither the
> PowerPC 64 one.

You have the choice to emulate SPE extensions only in the TARGET_PPC64
case. As you said it is slower, but you avoid ifdefs.

My last remark : "I'd say the same
about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU."
was unrelated to the SPE case. You have also the choice here to always
force it to 32 bit.

> [...]
>>> - someone provide an open-source hypervisor, compatible with the ones
>>> used on real machines, that would allow at least Linux to be able to run
>>> on a CPU with hypervisor mode available. Most 64 bits PowerPC, including
>>> the 970 (ie G5) have the hypervisor mode support implemented. If the
>>> hypervisor mode emulation is present, the OS won't be allowed to access
>>> most SPR and some exceptions will need to have some specific handlers in
>>> the hypervisor firmware. As I don't know such a software available, the
>>> hypervisor mode can not be enabled for "standard" PowerPC 64 emulation;
>>> or no-one will be able to actually use the emulator, except if using the
>>> venerable but mostly undocumented (and nearly impossible to find on real
>>> hardware) PowerPC 620 CPU.
>>> Furthermore, running (or emulating) a SMP machine on a 64 bits PowerPC
>>> with hypervisor features without hypervisor software is exactly
>>> impossible.
>>> Then I don't see how we can do without a separated target for hypervisor
>>> features support.
>> What you say does not justify the separate ppc64h target : it just
>> implies that you need to add a separate machine to make hypervisor tests.
> 
> There is no documented way to disable the hypervisor feature on 64 bits
> PowerPC CPUs, even if the Apple SMU is said to do this before the CPU
> boots (but there is no known way to check if it's true). Then, it will
> make all PowerPC 64 emulated (but the 602) unusable as there'll be no
> known OSS to manage them.
> Removing the ppc64h target means, for me, removing any option to emulate
> the hypervisor feature at any time (if removed) or removing the ability
> to use the PowerPC 64 targets the way they are when booting on Apple G5
> machines (if merged with the ppc64 target). None of those options seem
> acceptable to me.

Why not adding a new CPU type such as "PPC970 with hypervisor" and keep
the current PPC970 implementation as it is without the hypervisor mode.
I don't see the problem in replacing the ifdefs with a new CPU model !
You cannot reasonnably tell that it is uglier than the current code.

Fabrice.