Re: [PATCH 0/2] Make savevm versioning compatible with upstream QEMU
Anthony Liguori wrote: Right now, there is no way savevm versioning can be compatible with upstream QEMU because KVM adds fields to existing savevm structures without incrementing the versions. If you assume that KVM will eventually merge into upstream QEMU, this means that eventually KVM is going to have to break backwards compatibility with itself to resolve this issue in a non-graceful way. So let's do that now instead of doing it later when the situation is only worse. I'm happy to allocate particular version identifiers for KVM to avoid future conflicts. I believe we should try to eliminate the existing differences so that we can converge in the future on a common versioning scheme. Applied both, thanks. I think we can avoid the need to synchronize too much by saving kvm-specific state for device x using id x-kvm; this allows the two to evolve independently. Of course it's much better to avoid divergence in the first place, but this isn't always possible. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Make savevm versioning compatible with upstream QEMU
Avi Kivity wrote: Anthony Liguori wrote: Right now, there is no way savevm versioning can be compatible with upstream QEMU because KVM adds fields to existing savevm structures without incrementing the versions. If you assume that KVM will eventually merge into upstream QEMU, this means that eventually KVM is going to have to break backwards compatibility with itself to resolve this issue in a non-graceful way. So let's do that now instead of doing it later when the situation is only worse. I'm happy to allocate particular version identifiers for KVM to avoid future conflicts. I believe we should try to eliminate the existing differences so that we can converge in the future on a common versioning scheme. Applied both, thanks. I think we can avoid the need to synchronize too much by saving kvm-specific state for device x using id x-kvm; this allows the two to evolve independently. I need to add save/restore support to upstream QEMU so this is a good excuse to just merge the changes in KVM upstream. So hopefully this will become a non issue. If something arises and you need more savevm state, introduce a new section suffixed or prefixed with kvm. Alternatively, ask and I can reserve an ID upstream. For virtio-net, we just need to get the vnet stuff merged upstream. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Make savevm versioning compatible with upstream QEMU
Right now, there is no way savevm versioning can be compatible with upstream QEMU because KVM adds fields to existing savevm structures without incrementing the versions. If you assume that KVM will eventually merge into upstream QEMU, this means that eventually KVM is going to have to break backwards compatibility with itself to resolve this issue in a non-graceful way. So let's do that now instead of doing it later when the situation is only worse. I'm happy to allocate particular version identifiers for KVM to avoid future conflicts. I believe we should try to eliminate the existing differences so that we can converge in the future on a common versioning scheme. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
