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: Tue, 12 Feb 2008 10:45:56 +0000	[thread overview]
Message-ID: <47B178E4.6080304@qumranet.com> (raw)
In-Reply-To: <1202766950.1827.18.camel@basalt>

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/
_______________________________________________
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: Tue, 12 Feb 2008 12:45:56 +0200	[thread overview]
Message-ID: <47B178E4.6080304@qumranet.com> (raw)
In-Reply-To: <1202766950.1827.18.camel@basalt>

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/

  parent reply	other threads:[~2008-02-12 10:45 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 ` Avi Kivity [this message]
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     ` [kvm-ppc-devel] " Avi Kivity
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=47B178E4.6080304@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.