[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv3 0/2] Fix virtio-serial migration on bi-endian
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [PATCHv3 0/2] Fix virtio-serial migration on bi-endian targets |
Date: |
Fri, 19 Dec 2014 11:01:03 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
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