Re: [kvm-ppc-devel] [kvm-devel] upstream PowerPC qemu breakage

[Avi Kivity <avi@qumranet.com>]

Anthony Liguori wrote:
>
>> 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.
>

I don't think this is the right fix.  A machine type (if I understand it 
correctly) refers to a combination of a target processor, 
chipset/busses, and devices, not to how they are implemented in qemu.

I believe a better fix is to introduce an orthogonal 
--without-cpu-emulation.

-- 
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