From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: upstream PowerPC qemu breakage Date: Tue, 12 Feb 2008 12:45:56 +0200 Message-ID: <47B178E4.6080304@qumranet.com> References: <1202766950.1827.18.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel , kvm-devel To: Hollis Blanchard Return-path: In-Reply-To: <1202766950.1827.18.camel@basalt> 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 Hollis Blanchard wrote: > Hi Avi, we're having a problem with the qemu merge you just did in > kvm-userspace. > > Upstream qemu recently added the TCG code generator to phase out dyngen. > When he did that, Fabrice explicitly broke the build every non-x86 > architecture, and since you've now pulled that breakage into KVM, we're > stuck in an awkward situation. > > 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 :) . > I meant to drop Xiantao and you a note about this, but qemu merges tend to erase short-term memory. I figured that since tcg is not used when using kvm, you could just stub it out. The downside is that -no-kvm breaks, but we can live with that. > 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. > It kills -no-kvm, which is a powerful debugging aid. > Another long-term option is to fix TCG for PowerPC upstream, and I'm > afraid that isn't feasible. > I saw some talk that dyngen and tcg can coexist; but apparently that's not the case. Hopefully qemu upstream will unbreak the damage. > I guess merging with qemu while it's in a period of massive change > wasn't the most opportune moment. Were there some device model changes > you were eager to pick up? > The e1000 patch for one; also doing regular small merges is much easier than irregular large ones. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/