All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: [kvm-ppc-devel] upstream PowerPC qemu breakage
Date: Wed, 13 Feb 2008 06:58:34 +0000	[thread overview]
Message-ID: <47B2951A.8020308@qumranet.com> (raw)
In-Reply-To: <1202842578.21985.27.camel@basalt>

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-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@qumranet.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: upstream PowerPC qemu breakage
Date: Wed, 13 Feb 2008 08:58:34 +0200	[thread overview]
Message-ID: <47B2951A.8020308@qumranet.com> (raw)
In-Reply-To: <1202842578.21985.27.camel@basalt>

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/

  reply	other threads:[~2008-02-13  6:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11 21:55 [kvm-ppc-devel] upstream PowerPC qemu breakage Hollis Blanchard
2008-02-11 21:55 ` Hollis Blanchard
2008-02-11 22:55 ` [kvm-ppc-devel] [kvm-devel] " Anthony Liguori
2008-02-11 22:55   ` Anthony Liguori
2008-02-13  7:03   ` [kvm-ppc-devel] [kvm-devel] " Avi Kivity
2008-02-13  7:03     ` Avi Kivity
2008-02-12 10:45 ` [kvm-ppc-devel] " Avi Kivity
2008-02-12 10:45   ` Avi Kivity
2008-02-12 18:56   ` [kvm-ppc-devel] " Hollis Blanchard
2008-02-12 18:56     ` Hollis Blanchard
2008-02-13  6:58     ` Avi Kivity [this message]
2008-02-13  6:58       ` Avi Kivity
2008-02-16  0:26       ` [kvm-ppc-devel] " Hollis Blanchard
2008-02-16  0:26         ` Hollis Blanchard
2008-02-16  8:47         ` Avi Kivity
2008-02-16  8:47           ` Avi Kivity
2008-02-18 19:38           ` Hollis Blanchard
2008-02-18 19:38             ` Hollis Blanchard
2008-02-18 20:22             ` Avi Kivity
2008-02-18 20:22               ` Avi Kivity
2008-02-18 21:03               ` Hollis Blanchard
2008-02-18 21:03                 ` Hollis Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47B2951A.8020308@qumranet.com \
    --to=avi@qumranet.com \
    --cc=hollisb@us.ibm.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=kvm-ppc-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.