[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...
From: |
Thiemo Seufer |
Subject: |
Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... |
Date: |
Sat, 24 Nov 2007 00:18:19 +0000 |
User-agent: |
Mutt/1.5.17 (2007-11-01) |
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
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., (continued)
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Jocelyn Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Paul Brook, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Jocelyn Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Jocelyn Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Paul Brook, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., J. Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Paul Brook, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Thiemo Seufer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Fabrice Bellard, 2007/11/24
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., J. Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...,
Thiemo Seufer <=
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Paul Brook, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Julian Seward, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., J. Mayer, 2007/11/23
- Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., J. Mayer, 2007/11/23
[Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-..., Jocelyn Mayer, 2007/11/23