On Tue, 2008-02-12 at 12:45 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > > 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.
Build failures kill a lot more functionality than -no-kvm. Beyond the immediate issue, there is also the question of carrying the memory footprint for a bunch of functionality that we aren't using. I guess it could increase exposure security issues too. Generally, I don't see that it makes sense to build a bunch of code we don't use, especially if your only merge criterion is "x86 works"... (By the way, upstream qemu doesn't even support 440 or IA64 instruction emulation right now, so -no-kvm is worthless to us anyways.) > > 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. I have no reason to believe that's not true, in theory. In practice, we're broken right now... > Hopefully qemu upstream will unbreak the damage. What do you suggest, waiting until they fix it? -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
