From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ivij6-00080I-7U for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:18:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ivij4-0007zq-1G for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:18:27 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ivij3-0007zn-UJ for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:18:25 -0500 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ivij3-00022t-J3 for qemu-devel@nongnu.org; Fri, 23 Nov 2007 19:18:26 -0500 Date: Sat, 24 Nov 2007 00:18:19 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-... Message-ID: <20071124001819.GI9204@networkno.de> References: <200711232136.55819.paul@codesourcery.com> <1195855536.24893.21.camel@rapid> <200711232223.54239.paul@codesourcery.com> <1195861001.24893.40.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1195861001.24893.40.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org 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