From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: upstream PowerPC qemu breakage Date: Wed, 13 Feb 2008 09:03:22 +0200 Message-ID: <47B2963A.503@qumranet.com> References: <1202766950.1827.18.camel@basalt> <47B0D268.1000909@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel , kvm-devel , Hollis Blanchard To: Anthony Liguori Return-path: In-Reply-To: <47B0D268.1000909@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > >> In the short term we'll have to fork a working userspace, since we're in >> the middle of some other stuff (such as real guest IO, which I think is >> pretty important :) . >> >> Long term, one option is to try to define a new qemu target that >> completely bypasses the code generation parts of qemu. Anthony did that >> for x86 once, but there are at least a couple sticking points; not sure >> how long it will take. This is probably the best long-term way to avoid >> this situation in the future. >> > > This is very easy to do and is probably the best long term and short > term solution. If you introduce a new target type (ppcemb-kvm) and > drop the TCG/dyngen bits from the build for it, then you should be > okay. It will require a small stub file but there's not more than a > dozen or so functions required for that. > > I think this would be generally useful for other architectures too > (like ia64, s390, and even x86). At least ia64 and s390 aren't going > to have functioning translation bits so having a -kvm target really > makes a lot more sense than faking out a -softmmu target. > I don't think this is the right fix. A machine type (if I understand it correctly) refers to a combination of a target processor, chipset/busses, and devices, not to how they are implemented in qemu. I believe a better fix is to introduce an orthogonal --without-cpu-emulation. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/