Hollis Blanchard wrote: > 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. > >
I am not advocating that as a useful feature. > 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, > I think the fix for that is a compile time option to disable emulation. Just like you can disable kvm and kqemu support at compile time. > especially if your only merge criterion is "x86 works"... > I'll try to set up F8 ppc on a qemu instance, in order to reduce breakage in the future. As it is, many libkvm and qemu-kvm.c changes will break the build. It'll need to be built against your kernel tree; please provide a URL. > >> Hopefully qemu upstream will unbreak the damage. >> > > What do you suggest, waiting until they fix it? > > No. Stubbing out tcg-target.h as a band-aid, and --without-cpu-emulation ./configure switch as a long term fix (which you want anyway). -- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
