Hi,
> static const VMStateDescription vmstate_kbd = {
> .name = "pckbd",
> - .version_id = 3,
> + .version_id = 4,
> .minimum_version_id = 3,
> .post_load = kbd_post_load,
> .fields = (VMStateField[]) {
> @@ -435,6 +471,7 @@ static const VMStateDescription vmstate_kbd = {
> VMSTATE_UINT8(status, KBDState),
> VMSTATE_UINT8(mode, KBDState),
> VMSTATE_UINT8(pending, KBDState),
> + VMSTATE_UINT8_V(obdata, KBDState, 4),
> VMSTATE_END_OF_LIST()
> },
> .subsections = (const VMStateDescription*[]) {
> @@ -512,12 +549,20 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq
> a20_out)
> qdev_connect_gpio_out_named(DEVICE(dev), I8042_A20_LINE, 0, a20_out);
> }
Unfortunately live migration isn't that easy. Reason is we want able to
live-migrate both ways (old qemu -> new qemu but also new qemu -> old qemu).
With version ids we can do old qemu -> new qemu only.
So the usual way to deal with this is that new features which require
additional state information can be enabled/disabled at runtime using
device properties. The feature is turned off for the compatibility
machine types. The additional state is added using a conditional
subsection, which is only sent in case the feature is enabled. That way
qemu with -- says -- "-machine pc-q35-5.0" will only enable features and
sent vmstate which qemu 5.0 is able to deal with.
I think there is no way around such a property for the ps2 fixes, even
if we use it for sending/not sending the additional ps2 state
information needed by the bugfixes. Making the fixes itself conditional
should not be needed I think.
take care,
Gerd
