Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...

[Thiemo Seufer <ths@networkno.de>]

J. Mayer wrote:
[snip]
> >  Showing more than 32 bits of register 
> > is completely bogus.
> 
> No. It's showing the full CPU state, which can be more than what the
> application (or the OS, when running virtualized on a real CPU) could
> see. The OS cannot see the whole CPU state, but Qemu must implement more
> than the OS can see and is then able to dump it. 64 bits GPR is just a
> specific case of a general behavior.
> 
> >  Any differences between a 32-bit host and a 64-bit host 
> > are a qemu bug. If you display 64 bits, then those 64 bits had better be the 
> > same when run on 32-bit hosts.
> 
> Why ? The idea is that it costs too much to keep the whole state when
> running on a 32 bits host, then we act as a restricted embedded
> implementation. When the host CPU allows it without any extra cost, we
> act as the specification defines we should. This is a choice. Once
> again, this choice can be discussed and may be changed if I get
> convinced it would be better not to act this way. But this behavior is
> sure not bugged, it exactly follows (or may say should exactly if well
> implemented) the PowerPC specification.

Degrading the emulation capabilities in dependence of the host capabilities
with disregard of the user's requests sounds like a tremendously bad idea
to me. So

- If the high bits state is discoverable from guest software then it
  should always be emulated, independent of the host.
- If the high bits state is software transparent, then it should never
  be emulated. Even on a 64-bit host it will reduce performance as it
  moves more state through the caches. Moreover, the emulation will stay
  architecturally correct WRT to software execution, which is, I believe,
  the part of the spec which actually counts for QEMU.


Thiemo