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.
