[Qemu-devel] [PATCHv3 0/2] Fix virtio-serial migration on bi-endian targets

[David Gibson]

On a bi-endian target, with a guest in the non-default endian mode,
attempting to migrate twice in a row with a virtio-serial device wil
cause a qemu SEGV on the second outgoing migration.

The problem is that virtio_serial_save_device() (and other places) expect
VirtIOSerial->config to be in current guest endianness.  On a fresh boot,
virtio_serial_device_realize() will initialize VirtIOSerial->config in
default endianness.  It's assumed the guest OS will make its true
endianness known before the device is reset and initialized, then
vser_reset adjusts VirtIOSerial->config into the new endianness.

But on an incoming migration, the device isn't reset (after all the guest
has a running driver as far as it's concerned), which means that
VirtIOSerial->config retains its default endianness value from
virtio_serial_device_realize().

On a subsequent outgoing migration, virtio_serial_save_device() attempts
to interpret VirtIOSerial->config.max_nr_ports in current endianness when
its actually in default endianness and then runs off the end of the
ports_map array in the loop immediately afterwards.

We could fix this by adjusting VirtIOSerial->config into the correct
current endianness after an incoming migration.  But in fact we
already have a host endian copy of the max number of ports readily
available, so it's simpler to just use that instead.  Patch 1/2 does
that.

Once that's done, it becomes clear that there's really no reason to
keep the guest-endian copy of the config space around persistently
(config accesses aren't a fast path, so it can be constructed when
necessary).  Patch 2/2 makes that cleanup.