All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <guangrong.xiao@gmail.com>
To: Peter Xu <peterx@redhat.com>
Cc: kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com,
	Xiao Guangrong <xiaoguangrong@tencent.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com, wei.w.wang@intel.com,
	jiang.biao2@zte.com.cn, pbonzini@redhat.com
Subject: Re: [PATCH] migration: introduce decompress-error-check
Date: Fri, 27 Apr 2018 18:40:09 +0800	[thread overview]
Message-ID: <2f84ab90-2b9c-9888-e6e2-9114ae046078@gmail.com> (raw)
In-Reply-To: <20180427093135.GC13269@xz-mi>



On 04/27/2018 05:31 PM, Peter Xu wrote:
> On Fri, Apr 27, 2018 at 11:15:37AM +0800, Xiao Guangrong wrote:
>>
>>
>> On 04/26/2018 10:01 PM, Eric Blake wrote:
>>> On 04/26/2018 04:15 AM, guangrong.xiao@gmail.com wrote:
>>>> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>>>>
>>>> QEMU 2.13 enables strict check for compression & decompression to
>>>> make the migration more robuster, that depends on the source to fix
>>>
>>> s/robuster/robust/
>>>
>>
>> Will fix, thank you for pointing it out.
>>
>>>> the internal design which triggers the unexpected error conditions
>>>
>>> 2.13 hasn't been released yet.  Why do we need a knob to explicitly turn
>>> off strict checking?  Can we not instead make 2.13 automatically smart
>>> enough to tell if the incoming stream is coming from an older qemu
>>> (which might fail if the strict checks are enabled) vs. a newer qemu
>>> (the sender gave us what we need to ensure the strict checks are
>>> worthwhile)?
>>>
>>
>> Really smart.
>>
>> How about introduce a new command, MIG_CMD_DECOMPRESS_ERR_CHECK,
>> the destination will do strict check if got this command (i.e, new
>> QEMU is running on the source), otherwise, turn the check off.
> 
> Why not we just introduce a compat bit for that?  I mean something
> like: 15c3850325 ("migration: move skip_section_footers",
> 2017-06-28).  Then we turn that check bit off for <=2.12.
> 
> Would that work?

I am afraid it can not. :(

The compat bit only impacts local behavior, however, in this case, we
need the source QEMU to tell the destination if it supports strict
error check.

WARNING: multiple messages have this Message-ID (diff)
From: Xiao Guangrong <guangrong.xiao@gmail.com>
To: Peter Xu <peterx@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	pbonzini@redhat.com, mst@redhat.com, mtosatti@redhat.com,
	kvm@vger.kernel.org, Xiao Guangrong <xiaoguangrong@tencent.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com, wei.w.wang@intel.com,
	jiang.biao2@zte.com.cn
Subject: Re: [Qemu-devel] [PATCH] migration: introduce decompress-error-check
Date: Fri, 27 Apr 2018 18:40:09 +0800	[thread overview]
Message-ID: <2f84ab90-2b9c-9888-e6e2-9114ae046078@gmail.com> (raw)
In-Reply-To: <20180427093135.GC13269@xz-mi>



On 04/27/2018 05:31 PM, Peter Xu wrote:
> On Fri, Apr 27, 2018 at 11:15:37AM +0800, Xiao Guangrong wrote:
>>
>>
>> On 04/26/2018 10:01 PM, Eric Blake wrote:
>>> On 04/26/2018 04:15 AM, guangrong.xiao@gmail.com wrote:
>>>> From: Xiao Guangrong <xiaoguangrong@tencent.com>
>>>>
>>>> QEMU 2.13 enables strict check for compression & decompression to
>>>> make the migration more robuster, that depends on the source to fix
>>>
>>> s/robuster/robust/
>>>
>>
>> Will fix, thank you for pointing it out.
>>
>>>> the internal design which triggers the unexpected error conditions
>>>
>>> 2.13 hasn't been released yet.  Why do we need a knob to explicitly turn
>>> off strict checking?  Can we not instead make 2.13 automatically smart
>>> enough to tell if the incoming stream is coming from an older qemu
>>> (which might fail if the strict checks are enabled) vs. a newer qemu
>>> (the sender gave us what we need to ensure the strict checks are
>>> worthwhile)?
>>>
>>
>> Really smart.
>>
>> How about introduce a new command, MIG_CMD_DECOMPRESS_ERR_CHECK,
>> the destination will do strict check if got this command (i.e, new
>> QEMU is running on the source), otherwise, turn the check off.
> 
> Why not we just introduce a compat bit for that?  I mean something
> like: 15c3850325 ("migration: move skip_section_footers",
> 2017-06-28).  Then we turn that check bit off for <=2.12.
> 
> Would that work?

I am afraid it can not. :(

The compat bit only impacts local behavior, however, in this case, we
need the source QEMU to tell the destination if it supports strict
error check.

  reply	other threads:[~2018-04-27 10:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26  9:15 [PATCH] migration: introduce decompress-error-check guangrong.xiao
2018-04-26  9:15 ` [Qemu-devel] " guangrong.xiao
2018-04-26  9:19 ` Xiao Guangrong
2018-04-26  9:19   ` [Qemu-devel] " Xiao Guangrong
2018-04-26  9:34 ` Dr. David Alan Gilbert
2018-04-26  9:34   ` [Qemu-devel] " Dr. David Alan Gilbert
2018-04-26 13:18   ` Xiao Guangrong
2018-04-26 13:18     ` [Qemu-devel] " Xiao Guangrong
2018-04-26 14:01 ` Eric Blake
2018-04-26 14:01   ` [Qemu-devel] " Eric Blake
2018-04-27  3:15   ` Xiao Guangrong
2018-04-27  3:15     ` [Qemu-devel] " Xiao Guangrong
2018-04-27  9:31     ` Peter Xu
2018-04-27  9:31       ` [Qemu-devel] " Peter Xu
2018-04-27 10:40       ` Xiao Guangrong [this message]
2018-04-27 10:40         ` Xiao Guangrong
2018-05-02  3:03         ` Peter Xu
2018-05-02  3:03           ` [Qemu-devel] " Peter Xu
2018-05-02 14:57           ` Dr. David Alan Gilbert
2018-05-02 14:57             ` [Qemu-devel] " Dr. David Alan Gilbert
2018-05-03  2:10             ` Peter Xu
2018-05-03  2:10               ` [Qemu-devel] " Peter Xu
2018-04-27 11:29     ` Dr. David Alan Gilbert
2018-04-27 11:29       ` [Qemu-devel] " Dr. David Alan Gilbert
2018-04-28  6:13       ` Xiao Guangrong
2018-04-28  6:13         ` [Qemu-devel] " Xiao Guangrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f84ab90-2b9c-9888-e6e2-9114ae046078@gmail.com \
    --to=guangrong.xiao@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=jiang.biao2@zte.com.cn \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wei.w.wang@intel.com \
    --cc=xiaoguangrong@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.