qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v3] qemu: kvm: Enable XSAVE live migration suppo


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH v3] qemu: kvm: Enable XSAVE live migration support
Date: Thu, 17 Jun 2010 09:26:13 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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 <address@hidden>
>>>>> ---
>>>>>
>>>>>  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]