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
