All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
@ 2014-06-10  9:29 Peter Lieven
  2014-06-10 12:55 ` Eric Blake
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Lieven @ 2014-06-10  9:29 UTC (permalink / raw)
  To: qemu-devel; +Cc: quintela, Peter Lieven, dgilbert, amit.shah, pbonzini

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>
---
v3->v4: - throw error reports where possible [Amit]
        - removed the rework of the last case it missed
          BLOCK_MIG_FLAG_EOS and threw an error.
v2->v3: - reworked last case in the if statement
        - added an error_report in case of an unknown flag [David]
v1->v2: rework loop from do ... while to while [Juan]
 
 arch_init.c |   42 +++++++++++++++++++++++-------------------
 migration.c |    2 +-
 2 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 9f1a174..4ee782f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -1041,17 +1041,15 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
 {
     ram_addr_t addr;
     int flags, ret = 0;
-    int error;
     static uint64_t seq_iter;
 
     seq_iter++;
 
     if (version_id != 4) {
         ret = -EINVAL;
-        goto done;
     }
 
-    do {
+    while (!ret) {
         addr = qemu_get_be64(f);
 
         flags = addr & ~TARGET_PAGE_MASK;
@@ -1079,7 +1077,6 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
                                          " in != " RAM_ADDR_FMT, id, length,
                                          block->length);
                             ret =  -EINVAL;
-                            goto done;
                         }
                         break;
                     }
@@ -1089,21 +1086,22 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
                     error_report("Unknown ramblock \"%s\", cannot "
                                  "accept migration", id);
                     ret = -EINVAL;
-                    goto done;
+                }
+                if (ret) {
+                    break;
                 }
 
                 total_ram_bytes -= length;
             }
-        }
-
-        if (flags & RAM_SAVE_FLAG_COMPRESS) {
+        } else if (flags & RAM_SAVE_FLAG_COMPRESS) {
             void *host;
             uint8_t ch;
 
             host = host_from_stream_offset(f, addr, flags);
             if (!host) {
+                error_report("Illegal RAM offset %" PRIx64, addr);
                 ret = -EINVAL;
-                goto done;
+                break;
             }
 
             ch = qemu_get_byte(f);
@@ -1113,33 +1111,39 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
 
             host = host_from_stream_offset(f, addr, flags);
             if (!host) {
+                error_report("Illegal RAM offset %" PRIx64, addr);
                 ret = -EINVAL;
-                goto done;
+                break;
             }
 
             qemu_get_buffer(f, host, TARGET_PAGE_SIZE);
         } else if (flags & RAM_SAVE_FLAG_XBZRLE) {
             void *host = host_from_stream_offset(f, addr, flags);
             if (!host) {
+                error_report("Illegal RAM offset %" PRIx64, addr);
                 ret = -EINVAL;
-                goto done;
+                break;
             }
 
             if (load_xbzrle(f, addr, host) < 0) {
+                error_report("Failed to decompress XBZRLE page at %" PRIx64,
+                             addr);
                 ret = -EINVAL;
-                goto done;
+                break;
             }
         } else if (flags & RAM_SAVE_FLAG_HOOK) {
             ram_control_load_hook(f, flags);
+        } else if (flags & RAM_SAVE_FLAG_EOS) {
+            /* normal exit */
+            break;
+        } else {
+            error_report("Unknown migration flags: %#x", flags);
+            ret = -EINVAL;
+            break;
         }
-        error = qemu_file_get_error(f);
-        if (error) {
-            ret = error;
-            goto done;
-        }
-    } while (!(flags & RAM_SAVE_FLAG_EOS));
+        ret = qemu_file_get_error(f);
+    }
 
-done:
     DPRINTF("Completed load of VM with exit code %d seq iteration "
             "%" PRIu64 "\n", ret, seq_iter);
     return ret;
diff --git a/migration.c b/migration.c
index 3fc03d6..3ebe9fb 100644
--- a/migration.c
+++ b/migration.c
@@ -98,7 +98,7 @@ static void process_incoming_migration_co(void *opaque)
     qemu_fclose(f);
     free_xbzrle_decoded_buf();
     if (ret < 0) {
-        fprintf(stderr, "load of migration failed\n");
+        error_report("load of migration failed: %s", strerror(-ret));
         exit(EXIT_FAILURE);
     }
     qemu_announce_self();
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
  2014-06-10  9:29 [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load Peter Lieven
@ 2014-06-10 12:55 ` Eric Blake
  2014-06-10 13:00   ` Eric Blake
  2014-06-10 16:00   ` Juan Quintela
  0 siblings, 2 replies; 6+ messages in thread
From: Eric Blake @ 2014-06-10 12:55 UTC (permalink / raw)
  To: Peter Lieven, qemu-devel; +Cc: amit.shah, pbonzini, dgilbert, quintela

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
  2014-06-10 12:55 ` Eric Blake
@ 2014-06-10 13:00   ` Eric Blake
  2014-06-10 13:08     ` Peter Lieven
  2014-06-10 16:00   ` Juan Quintela
  1 sibling, 1 reply; 6+ messages in thread
From: Eric Blake @ 2014-06-10 13:00 UTC (permalink / raw)
  To: Peter Lieven, qemu-devel; +Cc: amit.shah, pbonzini, dgilbert, quintela

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

On 06/10/2014 06:55 AM, Eric Blake wrote:
> 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.
>>

>>          } 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?

For that matter, would it be better to change the if-tree into a switch,
so that the default case catches unsupported combinations?

switch (flags) {
  ...
  case RAM_SAVE_FLAG_HOOK: ...
  case RAM_SAVE_FLAG_EOS: ...
  default: report unsupported flags value
}

-- 
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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
  2014-06-10 13:00   ` Eric Blake
@ 2014-06-10 13:08     ` Peter Lieven
  2014-06-10 13:15       ` Dr. David Alan Gilbert
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Lieven @ 2014-06-10 13:08 UTC (permalink / raw)
  To: Eric Blake, qemu-devel; +Cc: amit.shah, pbonzini, dgilbert, quintela

On 10.06.2014 15:00, Eric Blake wrote:
> On 06/10/2014 06:55 AM, Eric Blake wrote:
>> 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.
>>>
>>>           } 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?
> For that matter, would it be better to change the if-tree into a switch,
> so that the default case catches unsupported combinations?
>
> switch (flags) {
>    ...
>    case RAM_SAVE_FLAG_HOOK: ...
>    case RAM_SAVE_FLAG_EOS: ...
>    default: report unsupported flags value
> }
>
The RAM_SAVE_FLAG_HOOK is the only real flag. It seems that the
flag value is used at least somewhere in the code of RDMA.

For that matter, we could handle the hook separately and everything
else in the switch statement. This would immediately solve the issue
of the very restricted space for the flags as we could use everything
below RAM_SAVE_FLAG_HOOK as counter immediately.

Looking at the code I further see that the hook function is made to return
an error code which is not checked at the moment.

Peter

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
  2014-06-10 13:08     ` Peter Lieven
@ 2014-06-10 13:15       ` Dr. David Alan Gilbert
  0 siblings, 0 replies; 6+ messages in thread
From: Dr. David Alan Gilbert @ 2014-06-10 13:15 UTC (permalink / raw)
  To: Peter Lieven; +Cc: amit.shah, pbonzini, qemu-devel, quintela

* Peter Lieven (pl@kamp.de) wrote:
> On 10.06.2014 15:00, Eric Blake wrote:
> >On 06/10/2014 06:55 AM, Eric Blake wrote:
> >>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.
> >>>
> >>>          } 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?
> >For that matter, would it be better to change the if-tree into a switch,
> >so that the default case catches unsupported combinations?
> >
> >switch (flags) {
> >   ...
> >   case RAM_SAVE_FLAG_HOOK: ...
> >   case RAM_SAVE_FLAG_EOS: ...
> >   default: report unsupported flags value
> >}
> >
> The RAM_SAVE_FLAG_HOOK is the only real flag. It seems that the
> flag value is used at least somewhere in the code of RDMA.

There's also RAM_SAVE_FLAG_CONTINUE that's used as a tweak to
make for smaller headers.

Dave

> For that matter, we could handle the hook separately and everything
> else in the switch statement. This would immediately solve the issue
> of the very restricted space for the flags as we could use everything
> below RAM_SAVE_FLAG_HOOK as counter immediately.
> 
> Looking at the code I further see that the hook function is made to return
> an error code which is not checked at the moment.
> 
> Peter
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load
  2014-06-10 12:55 ` Eric Blake
  2014-06-10 13:00   ` Eric Blake
@ 2014-06-10 16:00   ` Juan Quintela
  1 sibling, 0 replies; 6+ messages in thread
From: Juan Quintela @ 2014-06-10 16:00 UTC (permalink / raw)
  To: Eric Blake; +Cc: amit.shah, pbonzini, Peter Lieven, qemu-devel, dgilbert

Eric Blake <eblake@redhat.com> wrote:
> 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?

Migration Format?  Documented? O:-)

Now, more seriously, current code don't allows for more than one flag to
be enabled at the same time.  RAM_SAVE_FLAG_HOOK is always sent alone by
itself.

And old code just accepted silently unknown flags, this change makes
unknown flags to just fail the migration.  What is the only sensible
thing to do IMHO O:-)

Thanks, Juan.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-06-10 16:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-10  9:29 [Qemu-devel] [PATCHv4] migration: catch unknown flags in ram_load Peter Lieven
2014-06-10 12:55 ` Eric Blake
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

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.