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

[Amit Shah <amit.shah@redhat.com>]

On (Fri) 19 Dec 2014 [14:57:25], David Gibson wrote:
> 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.

Thanks, applied.

		Amit