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.
Thank you for the detailed information. This is really helpful.
I will send a version 4 series. It may take a few days.
With best regards,
Volker
take care,
Gerd
