Merging KVM QEMU changes upstream

Merging KVM QEMU changes upstream

[Anthony Liguori]

Hi,

As most probably know, the KVM project has been maintaining a QEMU tree 
for some time now.  Beyond support for the KVM kernel interface, the 
tree also contains a number of useful features like live migration, 
virtio, and extboot.  Some of these things have been posted to 
qemu-devel already but were not included.

I would like to work on merging the KVM changes into upstream QEMU but 
before I started that work, I wanted to get a read on how difficult it 
would be.  A lot of these things were designed specifically for KVM on 
x86.  Only now are other architectures starting to be considered.  
Certainly, cross-architecture emulation hasn't really been considered.

I wouldn't expect anything to be merged that caused a regression for 
cross-architecture emulation, but I don't really have the time to get a 
lot of the new features working for the cross-architecture case.  I 
would expect, though, that if these things were merged, it would make it 
relatively easy for someone else to do that though.

Is this a reasonable merge strategy?  We won't introduce regressions but 
I can't guarantee these new things will work cross-architecture.

Regards,

Anthony Liguori

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

Re: [Qemu-devel] Merging KVM QEMU changes upstream

[Paul Brook]

> Is this a reasonable merge strategy?  We won't introduce regressions but
> I can't guarantee these new things will work cross-architecture.

I think it depends to some extent whether things will need rewriting to be 
made cross-architecture. In particular if this requires interface changes.  
This means either breaking existing guests, or having to support both 
interfaces.

e.g. the extboot stuff seems like something that should be usable by all 
targets, except that the current interface looks like it's inherently x86 
specific.

Paul

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

Re: [Qemu-devel] Merging KVM QEMU changes upstream

[Anthony Liguori]

Paul Brook wrote:
>> Is this a reasonable merge strategy?  We won't introduce regressions but
>> I can't guarantee these new things will work cross-architecture.
>>     
>
> I think it depends to some extent whether things will need rewriting to be 
> made cross-architecture. In particular if this requires interface changes.  
> This means either breaking existing guests, or having to support both 
> interfaces.
>   

That's a reasonable stance to take.  I don't think anything in the tree 
right now presents that problem.  I'll start sending out some patches 
and if you have specific concerns, we can talk about them 1-by-1.

> e.g. the extboot stuff seems like something that should be usable by all 
> targets, except that the current interface looks like it's inherently x86 
> specific.
>   

Well with extboot in particular, the only interface is between the 
extboot option ROM and QEMU and I don't think that breaking that 
interface will matter much in practice.

Regards,

Anthony Liguori

> Paul
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


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