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: Volker Rümelin
Subject: Re: [PATCH 3/3] ps2: migration support for command reply queue
Date: Tue, 10 Aug 2021 07:05:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

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

Hi Gerd,

this part actually works. .needed is only evaluated on the sending side. For the receiving side subsections are optional. Migration doesn't fail if a subsection isn't loaded. Before I sent this patch series one of the migration tests was a migration from 6.0.92 to 6.0.92 with one byte in the command reply queue and 3 bytes in the scancode queue. The migration didn't fail.

Migration will fail in the rare case when a new QEMU sends the command_reply_queue subsection to an old QEMU version.

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.

What is the best way to add such a compat property? The ps2 keyboard isn't a qdev device. I can't just add a property to the device class. Do I have to add a property to the i8042 and the pl050 device and propagate the property value with the ps2_kbd_init() call to the PS2KbdState?

With best regards,
Volker

take care,
   Gerd





reply via email to

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