Merging KVM QEMU changes upstream
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/
A message that is not in the archive (sent off-list or not yet received): 479A222E.4-r/[email protected]
Quoted 2 lines
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/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Paul Brook
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 11 lines
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel