Sheng Yang wrote: > On Thursday 17 June 2010 00:05:44 Marcelo Tosatti wrote: >> On Wed, Jun 16, 2010 at 05:48:46PM +0200, Jan Kiszka wrote: >>> Marcelo Tosatti wrote: >>>> On Fri, Jun 11, 2010 at 12:36:49PM +0800, Sheng Yang wrote: >>>>> Signed-off-by: Sheng Yang <sheng@xxxxxxxxxxxxxxx> >>>>> --- >>>>> >>>>> qemu-kvm-x86.c | 109 >>>>> ++++++++++++++++++++++++++++++++++++++++--------- qemu-kvm.c >>>>> | 24 +++++++++++ >>>>> qemu-kvm.h | 28 +++++++++++++ >>>>> target-i386/cpu.h | 5 ++ >>>>> target-i386/kvm.c | 2 + >>>>> target-i386/machine.c | 20 +++++++++ >>>>> 6 files changed, 169 insertions(+), 19 deletions(-) >>>> Applied, thanks. >>> Oops, late remark: Why introducing this feature against qemu-kvm instead >>> of upstream? Doesn't this just generate additional conversion work and >>> the risk of divergence to upstream in the migration protocol? > > Hi Jan > > You're late... Hope you could raise the comment earlier next time so we can work > together more efficient. This case is "lost", probably was already when you posted the first time. But I hope we can raise awareness for the issue that way again. >> Thats true. Sheng, can you add save/restore support to uq/master to >> avoid these problems? > > Yes, there is divergence risk, would send an upstream version as well. > > But I think as long as qemu-kvm and qemu upstream use different LM path, the > duplicate code/work can't be avoid. Probably. The vision is that one day you can write a KVM feature and apply it to qemu-kvm as a staging tree for later unmodified merge into qemu upstream. qemu-kvm[-arch].[ch] is still in our way, but it already uses many bits from upstream. So I would recommend to design new features against upstream first and then provide the few bits to also make use of it in qemu-kvm once the latter has merged the required bits (which may actually happen before upstream, but that doesn't matter). Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
