All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	kvm-devel <kvm-devel@lists.sourceforge.net>,
	Avi Kivity <avi@qumranet.com>
Subject: Re: [kvm-ppc-devel] [kvm-devel] upstream PowerPC qemu breakage
Date: Mon, 11 Feb 2008 22:55:36 +0000	[thread overview]
Message-ID: <47B0D268.1000909@codemonkey.ws> (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.
>   

This sucks.  This seems like a big step backwards for QEMU since it 
doesn't appear that there is an obvious way to fix things for non-x86 hosts.

> 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 :) .
>
> 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.
>   

This is very easy to do and is probably the best long term and short 
term solution.  If you introduce a new target type (ppcemb-kvm) and drop 
the TCG/dyngen bits from the build for it, then you should be okay.  It 
will require a small stub file but there's not more than a dozen or so 
functions required for that.

I think this would be generally useful for other architectures too (like 
ia64, s390, and even x86).  At least ia64 and s390 aren't going to have 
functioning translation bits so having a -kvm target really makes a lot 
more sense than faking out a -softmmu target.

Regards,

Anthony Liguori

> Another long-term option is to fix TCG for PowerPC upstream, and I'm
> afraid that isn't feasible.
>
> 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?
>
>   


-------------------------------------------------------------------------
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: Anthony Liguori <anthony@codemonkey.ws>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	kvm-devel <kvm-devel@lists.sourceforge.net>,
	Avi Kivity <avi@qumranet.com>
Subject: Re: upstream PowerPC qemu breakage
Date: Mon, 11 Feb 2008 16:55:36 -0600	[thread overview]
Message-ID: <47B0D268.1000909@codemonkey.ws> (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.
>   

This sucks.  This seems like a big step backwards for QEMU since it 
doesn't appear that there is an obvious way to fix things for non-x86 hosts.

> 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 :) .
>
> 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.
>   

This is very easy to do and is probably the best long term and short 
term solution.  If you introduce a new target type (ppcemb-kvm) and drop 
the TCG/dyngen bits from the build for it, then you should be okay.  It 
will require a small stub file but there's not more than a dozen or so 
functions required for that.

I think this would be generally useful for other architectures too (like 
ia64, s390, and even x86).  At least ia64 and s390 aren't going to have 
functioning translation bits so having a -kvm target really makes a lot 
more sense than faking out a -softmmu target.

Regards,

Anthony Liguori

> Another long-term option is to fix TCG for PowerPC upstream, and I'm
> afraid that isn't feasible.
>
> 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?
>
>   


-------------------------------------------------------------------------
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-11 22:55 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 ` Anthony Liguori [this message]
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     ` [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=47B0D268.1000909@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=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.