diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2014-11-27 16:48:10 +1100 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2014-11-28 13:06:00 +0000 |
commit | db12451decf7dfe0f083564183e135f2095228b9 (patch) | |
tree | e32476479f04b46d0f59af67bb4e1d5192ae7b14 /xen-mapcache.c | |
parent | 771b6ed37e3aa188a7485560b949a41c6cf174dc (diff) | |
download | hqemu-db12451decf7dfe0f083564183e135f2095228b9.zip hqemu-db12451decf7dfe0f083564183e135f2095228b9.tar.gz |
Fix for crash after migration in virtio-rng on bi-endian targets
VirtIO devices now remember which endianness they're operating in in order
to support targets which may have guests of either endianness, such as
powerpc. This endianness state is transferred in a subsection of the
virtio device's information.
With virtio-rng this can lead to an abort after a loadvm hitting the
assert() in virtio_is_big_endian(). This can be reproduced by doing a
migrate and load from file on a bi-endian target with a virtio-rng device.
The actual guest state isn't particularly important to triggering this.
The cause is that virtio_rng_load_device() calls virtio_rng_process() which
accesses the ring and thus needs the endianness. However,
virtio_rng_process() is called via virtio_load() before it loads the
subsections. Essentially the ->load callback in VirtioDeviceClass should
only be used for actually reading the device state from the stream, not for
post-load re-initialization.
This patch fixes the bug by moving the virtio_rng_process() after the call
to virtio_load(). Better yet would be to convert virtio to use vmsd and
have the virtio_rng_process() as a post_load callback, but that's a bigger
project for another day.
This is bugfix, and should be considered for the 2.2 branch.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Message-id: 1417067290-20715-1-git-send-email-david@gibson.dropbear.id.au
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Diffstat (limited to 'xen-mapcache.c')
0 files changed, 0 insertions, 0 deletions