From: David Gibson <david@gibson.dropbear.id.au>
To: mst@redhat.com, amit.shah@redhat.com, rusty@rustcorp.com.au
Cc: aik@ozlabs.ru, David Gibson <david@gibson.dropbear.id.au>,
agraf@suse.de, mdroth@us.ibm.com, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targets
Date: Fri, 12 Dec 2014 16:26:35 +1100 [thread overview]
Message-ID: <1418361995-24091-1-git-send-email-david@gibson.dropbear.id.au> (raw)
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 a better fix is just
to get rid of VirtIOSerial->config entirely:
* The virtio-serial config space is not settable, it always contains the
values set at initialization
* AFAICT "rows" and "cols" have never actually been used for anything and
are always zero.
* "max_nr_ports" is initialized from
VirtIOSerial->serial.max_virtserial_ports (host endian)
So instead of maintaining this pointless guest-endian cache of the config
data, we can just construct it directly into the correct current guest
endian in the get_config hook. Current users of ->config can instead use
the sources from which the config values were derived, which means they
don't have to mess about with converting from guest endian at all.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
hw/char/virtio-serial-bus.c | 42 +++++++++++++++------------------------
include/hw/virtio/virtio-serial.h | 2 --
2 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index a7b1b68..dd5d7ec 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -482,10 +482,14 @@ static uint32_t get_features(VirtIODevice *vdev, uint32_t features)
/* Guest requested config info */
static void get_config(VirtIODevice *vdev, uint8_t *config_data)
{
- VirtIOSerial *vser;
-
- vser = VIRTIO_SERIAL(vdev);
- memcpy(config_data, &vser->config, sizeof(struct virtio_console_config));
+ VirtIOSerial *vser = VIRTIO_SERIAL(vdev);
+ struct virtio_console_config *config =
+ (struct virtio_console_config *)config_data;
+
+ config->cols = 0;
+ config->rows = 0;
+ config->max_nr_ports = virtio_tswap32(vdev,
+ vser->serial.max_virtserial_ports);
}
static void guest_reset(VirtIOSerial *vser)
@@ -533,10 +537,6 @@ static void vser_reset(VirtIODevice *vdev)
vser = VIRTIO_SERIAL(vdev);
guest_reset(vser);
-
- /* In case we have switched endianness */
- vser->config.max_nr_ports =
- virtio_tswap32(vdev, vser->serial.max_virtserial_ports);
}
static void virtio_serial_save(QEMUFile *f, void *opaque)
@@ -552,14 +552,14 @@ static void virtio_serial_save_device(VirtIODevice *vdev, QEMUFile *f)
uint32_t nr_active_ports;
unsigned int i, max_nr_ports;
- /* The config space */
- qemu_put_be16s(f, &s->config.cols);
- qemu_put_be16s(f, &s->config.rows);
+ max_nr_ports = s->serial.max_virtserial_ports;
- qemu_put_be32s(f, &s->config.max_nr_ports);
+ /* Used to be config space, now redundant */
+ qemu_put_be16(f, 0);
+ qemu_put_be16(f, 0);
+ qemu_put_be32(f, virtio_tswap32(vdev, max_nr_ports));
/* The ports map */
- max_nr_ports = virtio_tswap32(vdev, s->config.max_nr_ports);
for (i = 0; i < (max_nr_ports + 31) / 32; i++) {
qemu_put_be32s(f, &s->ports_map[i]);
}
@@ -715,13 +715,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
qemu_get_be16s(f, (uint16_t *) &tmp);
qemu_get_be32s(f, &tmp);
- /* Note: this is the only location where we use tswap32() instead of
- * virtio_tswap32() because:
- * - virtio_tswap32() only makes sense when the device is fully restored
- * - the target endianness that was used to populate s->config is
- * necessarly the default one
- */
- max_nr_ports = tswap32(s->config.max_nr_ports);
+ max_nr_ports = s->serial.max_virtserial_ports;
for (i = 0; i < (max_nr_ports + 31) / 32; i++) {
qemu_get_be32s(f, &ports_map);
@@ -784,10 +778,9 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
/* This function is only used if a port id is not provided by the user */
static uint32_t find_free_port_id(VirtIOSerial *vser)
{
- VirtIODevice *vdev = VIRTIO_DEVICE(vser);
unsigned int i, max_nr_ports;
- max_nr_ports = virtio_tswap32(vdev, vser->config.max_nr_ports);
+ max_nr_ports = vser->serial.max_virtserial_ports;
for (i = 0; i < (max_nr_ports + 31) / 32; i++) {
uint32_t map, bit;
@@ -848,7 +841,6 @@ static void virtser_port_device_realize(DeviceState *dev, Error **errp)
VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(dev);
VirtIOSerialPortClass *vsc = VIRTIO_SERIAL_PORT_GET_CLASS(port);
VirtIOSerialBus *bus = VIRTIO_SERIAL_BUS(qdev_get_parent_bus(dev));
- VirtIODevice *vdev = VIRTIO_DEVICE(bus->vser);
int max_nr_ports;
bool plugging_port0;
Error *err = NULL;
@@ -890,7 +882,7 @@ static void virtser_port_device_realize(DeviceState *dev, Error **errp)
}
}
- max_nr_ports = virtio_tswap32(vdev, port->vser->config.max_nr_ports);
+ max_nr_ports = port->vser->serial.max_virtserial_ports;
if (port->id >= max_nr_ports) {
error_setg(errp, "virtio-serial-bus: Out-of-range port id specified, "
"max. allowed: %u", max_nr_ports - 1);
@@ -995,8 +987,6 @@ static void virtio_serial_device_realize(DeviceState *dev, Error **errp)
vser->ovqs[i] = virtio_add_queue(vdev, 128, handle_output);
}
- vser->config.max_nr_ports =
- virtio_tswap32(vdev, vser->serial.max_virtserial_ports);
vser->ports_map = g_malloc0(((vser->serial.max_virtserial_ports + 31) / 32)
* sizeof(vser->ports_map[0]));
/*
diff --git a/include/hw/virtio/virtio-serial.h b/include/hw/virtio/virtio-serial.h
index a679e54..11af978 100644
--- a/include/hw/virtio/virtio-serial.h
+++ b/include/hw/virtio/virtio-serial.h
@@ -207,8 +207,6 @@ struct VirtIOSerial {
/* bitmap for identifying active ports */
uint32_t *ports_map;
- struct virtio_console_config config;
-
struct VirtIOSerialPostLoad *post_load;
virtio_serial_conf serial;
--
2.1.0
next reply other threads:[~2014-12-12 5:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 5:26 David Gibson [this message]
2014-12-15 14:59 ` [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targets Alexander Graf
2014-12-16 1:19 ` David Gibson
2014-12-16 4:13 ` Amit Shah
2014-12-16 4:33 ` David Gibson
2014-12-16 4:38 ` Amit Shah
2014-12-16 5:38 ` David Gibson
2014-12-16 6:07 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1418361995-24091-1-git-send-email-david@gibson.dropbear.id.au \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=amit.shah@redhat.com \
--cc=mdroth@us.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).