Re: upstream PowerPC qemu breakage

[Anthony Liguori <anthony@codemonkey.ws>]

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/