qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] ps2: migration support for command reply queue


From: Gerd Hoffmann
Subject: Re: [PATCH 3/3] ps2: migration support for command reply queue
Date: Mon, 9 Aug 2021 12:18:08 +0200

  Hi,

> +static bool ps2_keyboard_cqueue_needed(void *opaque)
> +{
> +    PS2KbdState *s = opaque;
> +
> +    return s->common.queue.cwptr != -1; /* the queue is mostly empty */
> +}
> +
> +static const VMStateDescription vmstate_ps2_keyboard_cqueue = {
> +    .name = "ps2kbd/command_reply_queue",
> +    .needed = ps2_keyboard_cqueue_needed,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_INT32(common.queue.cwptr, PS2KbdState),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};

Not going to work (the existing vmstate_ps2_keyboard_need_high_bit has
the same problem btw).  Chicken and egg problem on the receiving side:
How you properly evaluate ps2_keyboard_cqueue_needed() without having
common.queue.cwptr received yet?

With "cqueue not needed" being the common case migration will work
nicely in most cases nevertheless, but when the source machine actually
sends cqueue state things will break ...

Looking at data sent via vmstate works but ordering is important.  You
could check write_cmd because that is sent in the migration data stream
before ps2_keyboard_cqueue_needed() will be evaluated (just an random
example for the ordering, probably wouldn't help much in this case).

There is some redundancy in the data stream (wptr + rptr would be
enough, but we also send count).  Maybe that can be used somehow.
Of course the tricky part is to not confuse old qemu versions on
the receiving end.

If we can't find something we can add a property simliar to the one
for the extended keyboard state.

take care,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]