On Sat, 11 Jul 2020 13:40:50 +0200
Claudio Fontana <[email protected]> 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)?
