Re: upstream PowerPC qemu breakage

[Avi Kivity <avi@qumranet.com>]

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/