Re: [PATCH v3] qemu: kvm: Enable XSAVE live migration support

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

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@linux.intel.com>
>>>>> ---
>>>>>
>>>>>  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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]