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

[J. Mayer]

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.

[...]
> > - 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.

-- 
J. Mayer <address@hidden>
Never organized