Re: [PATCH 3/3] cpu-timers, icount: new modules

[Cornelia Huck <cohuck@redhat.com>]

On Sat, 11 Jul 2020 13:40:50 +0200
Claudio Fontana <cfontana@suse.de> wrote:

> I found out something that for me shows that more investigation here is warranted.
> 
> 
> Here is my latest workaround for the problem:
> 
> 
> 
> diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> index 1e036cc602..47c9a015af 100644
> --- a/hw/s390x/s390-skeys.c
> +++ b/hw/s390x/s390-skeys.c
> @@ -252,6 +252,8 @@ static const TypeInfo qemu_s390_skeys_info = {
>      .class_size    = sizeof(S390SKeysClass),
>  };
>  
> +extern void qemu_fflush(QEMUFile *f);
> +
>  static void s390_storage_keys_save(QEMUFile *f, void *opaque)
>  {
>      S390SKeysState *ss = S390_SKEYS(opaque);
> @@ -302,6 +304,7 @@ static void s390_storage_keys_save(QEMUFile *f, void *opaque)
>      g_free(buf);
>  end_stream:
>      qemu_put_be64(f, eos);
> +    qemu_fflush(f);
>  }
>  
>  static int s390_storage_keys_load(QEMUFile *f, void *opaque, int version_id)
> ------------------------------------------------------------------------------------
> 
> 
> I think that this might imply that my patch changing the migration stream has only triggered an existing problem.

Looks a bit like it.

> 
> The sympthom is: the load keys code does not see the EOS (byte value 1).
> It does see the keys (which are all empty in the test, ie 32678 times the byte value 0). 

Yes, that (zero keys) is expected.

> 
> The workaround for the sympthom: flush the qemu file after putting the EOS in there.
> 
> 
> Any ideas on where to investigate next?

Do any other users of the SaveVMHandlers interface see errors as well
(or do they do the fflush dance)?