qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org
Cc: amit.shah@redhat.com, pbonzini@redhat.com, dgilbert@redhat.com,
	quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
Date: Tue, 10 Jun 2014 06:55:46 -0600	[thread overview]
Message-ID: <53970052.4040402@redhat.com> (raw)
In-Reply-To: <1402392556-21844-1-git-send-email-pl@kamp.de>

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

On 06/10/2014 03:29 AM, Peter Lieven wrote:
> if a saved vm has unknown flags in the memory data qemu
> currently simply ignores this flag and continues which
> yields in an unpredictable result.
> 
> This patch catches all unknown flags and aborts the
> loading of the vm. Additionally error reports are thrown
> if the migration aborts abnormally.
> 
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---

> +    while (!ret) {
>          addr = qemu_get_be64(f);
>  
>          flags = addr & ~TARGET_PAGE_MASK;

> -
> -        if (flags & RAM_SAVE_FLAG_COMPRESS) {
> +        } else if (flags & RAM_SAVE_FLAG_COMPRESS) {
>              void *host;

>          } else if (flags & RAM_SAVE_FLAG_XBZRLE) {

>          } else if (flags & RAM_SAVE_FLAG_HOOK) {
>              ram_control_load_hook(f, flags);
> +        } else if (flags & RAM_SAVE_FLAG_EOS) {

Umm, is the migration format specifically documented as having at most
one flag per operation, or is it valid to send two flags at once?  That
is, can I send RAM_SAVE_FLAG_XBZRLE | RAM_SAVE_FLAG_HOOK on a single
packet?  Should we be flagging streams that send unexpected flag
combinations as invalid, even when each flag is in isolation okay,
rather than the current behavior of silently prioritizing one flag and
ignoring the other?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2014-06-10 12:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10  9:29 [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load Peter Lieven
2014-06-10 12:55 ` Eric Blake [this message]
2014-06-10 13:00   ` Eric Blake
2014-06-10 13:08     ` Peter Lieven
2014-06-10 13:15       ` Dr. David Alan Gilbert
2014-06-10 16:00   ` Juan Quintela

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=53970052.4040402@redhat.com \
    --to=eblake@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).