On 19.12.14 04:57, 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.
Please provide a version history of changes between versions. Also for patches you'd expect PPC people to read, CC qemu-ppc (maybe doesn't apply to this patch, but does to others) ;) Alex
