Re: [PATCH 1/5] migration: Make RAM_SAVE_FLAG_HOOK a normal case entry

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, May 04, 2023 at 01:44:39PM +0200, Juan Quintela wrote:
> Fixes this commit, clearly a bad merge after a rebase or similar, it
> should have been its own case since that point.
> 
> commit 5b0e9dd46fbda5152566a4a26fd96bc0d0452bf7
> Author: Peter Lieven <pl@kamp.de>
> Date:   Tue Jun 24 11:32:36 2014 +0200
> 
>     migration: catch unknown flag combinations in ram_load
> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  migration/ram.c | 12 +++++-------
>  1 file changed, 5 insertions(+), 7 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 7d81c4a39e..43338e1f5b 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4445,14 +4445,12 @@ static int ram_load_precopy(QEMUFile *f)
>                  multifd_recv_sync_main();
>              }
>              break;
> +        case RAM_SAVE_FLAG_HOOK:
> +            ram_control_load_hook(f, RAM_CONTROL_HOOK, NULL);
> +            break;
>          default:
> -            if (flags & RAM_SAVE_FLAG_HOOK) {
> -                ram_control_load_hook(f, RAM_CONTROL_HOOK, NULL);

The only use of this flag is

  rdma.c:    qemu_put_be64(f, RAM_SAVE_FLAG_HOOK);

so its is impossible for 'flags' to have other bits set when
we see RAM_SAVE_FLAG_HOOK, so although this change is not
semantically equivalent in the general case, it is equivalent
given our current usage.


Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|