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