From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpuSP-0000vk-Nv for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:37:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpuSP-0000vO-9a for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:37:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpuSP-0000vD-25 for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:37:13 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IpuSO-0003Yb-LP for qemu-devel@nongnu.org; Wed, 07 Nov 2007 18:37:12 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Removal of some target CPU macros Date: Wed, 7 Nov 2007 23:37:10 +0000 References: <473204A2.3030208@bellard.org> <200711072247.53354.paul@codesourcery.com> <1194476814.21588.24.camel@rapid> In-Reply-To: <1194476814.21588.24.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711072337.10814.paul@nowt.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "J. Mayer" > I can check the hypervisor feature is not present, for emulating PowerPC > 620 on a target that would have hypervisor emulation support. But I > cannot do as if the CPU do not have the feature if it's actually > available. The PowerPC 64 target emulates PowerPC 64 without the > hypervisor feature, which actually do not exist but looks like a G5 > machine when running Linux on it. If the emulator has the hypervisor > feature enabled, I need an hypervisor software to boot and manage the > machine I agree with this much. > There is nothing in the CPU that would allow me to > make it run "as if the hypervisor mode do not exists". So add one. It obviously exists conceptually, because that's what the non-hypervisor qemu emulates. > The only possible runtime solution would be to > duplicate every defined 64 bits CPU to define one model supporting > hypervisor feature and another acting as this feature do not exist (the > register definitions / access rights are not the same, and are defined > at CPU instanciation time, adding run-time checks there would cost a > lot...) and hope run-time checks won't cost too much. As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H I'd expect the runtime overhead to be minimal, if it's measurable at all. I'm not sure what you're getting at about flags being defined at instantiation time. That's the same whether you have two binaries or one. Duplicating the CPU definitions should also be fairly trivial. You're effectively already doing it when you build the separate ppc64 and ppc64h binaries. I find it hard to believe it would be hard to do the same transformation at runtime. Paul