From: Jason Wang <jasowang@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH V2 4/8] virtio-pci: fix 1.0 virtqueue migration
Date: Mon, 7 Sep 2015 15:39:59 +0800 [thread overview]
Message-ID: <55ED3F4F.4060504@redhat.com> (raw)
In-Reply-To: <20150902130630.662ae71b.cornelia.huck@de.ibm.com>
On 09/02/2015 07:06 PM, Cornelia Huck wrote:
> On Wed, 2 Sep 2015 11:25:21 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> We don't migrate the followings fields for virtio-pci:
>>
>> uint32_t dfselect;
>> uint32_t gfselect;
>> uint32_t guest_features[2];
>> struct {
>> uint16_t num;
>> bool enabled;
>> uint32_t desc[2];
>> uint32_t avail[2];
>> uint32_t used[2];
>> } vqs[VIRTIO_QUEUE_MAX];
>>
>> This will confuse driver if migrating during initialization. Solves
>> this issue by:
>>
>> - introduce transport specific callbacks to load and store extra
>> virtqueue states.
>> - add a new subsection for virtio to migrate transport specific modern
>> device state.
>> - implement pci specific callbacks.
>> - add a new property for virtio-pci for whether or not to migrate
>> extra state.
>> - compat the migration for 2.4 and elder machine types
>>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> hw/virtio/virtio-pci.c | 129 +++++++++++++++++++++++++++++++++++++++++
>> hw/virtio/virtio-pci.h | 20 ++++---
>> hw/virtio/virtio.c | 57 ++++++++++++++++++
>> include/hw/compat.h | 6 +-
>> include/hw/virtio/virtio-bus.h | 3 +
>> 5 files changed, 207 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
>> index c024161..a96890b 100644
>> --- a/hw/virtio/virtio-pci.c
>> +++ b/hw/virtio/virtio-pci.c
>> @@ -86,6 +86,129 @@ static void virtio_pci_save_config(DeviceState *d, QEMUFile *f)
>> qemu_put_be16(f, vdev->config_vector);
>> }
>>
>> +static void virtio_pci_load_modern_queue_state(VirtIOPCIQueue *vq,
>> + QEMUFile *f)
>> +{
>> + vq->num = qemu_get_be16(f);
>> + vq->enabled = qemu_get_be16(f);
>> + vq->desc[0] = qemu_get_be32(f);
>> + vq->desc[1] = qemu_get_be32(f);
>> + vq->avail[0] = qemu_get_be32(f);
>> + vq->avail[1] = qemu_get_be32(f);
>> + vq->used[0] = qemu_get_be32(f);
>> + vq->used[1] = qemu_get_be32(f);
>> +}
>> +
>> +static bool virtio_pci_has_extra_state(DeviceState *d)
>> +{
>> + VirtIOPCIProxy *proxy = to_virtio_pci_proxy(d);
>> +
>> + return proxy->flags & VIRTIO_PCI_FLAG_MIGRATE_EXTRA;
> Hm, couldn't you already check whether this is a modern device here?
> You don't need to save state for a legacy device, do you?
It was prepared for future. If we have something more that needs to be
migrated specifically for virtio-pci. We could just add a new subsection
for vmstate_virtio_pci without touching the core again. So we check the
modern in its subsection instead of here.
>
>> +}
>> +
> (...)
>
>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>> index 788b556..dcaf022 100644
>> --- a/hw/virtio/virtio.c
>> +++ b/hw/virtio/virtio.c
>> @@ -1056,6 +1056,16 @@ static bool virtio_virtqueue_needed(void *opaque)
>> return virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1);
>> }
>>
>> +static bool virtio_extra_state_needed(void *opaque)
>> +{
>> + VirtIODevice *vdev = opaque;
>> + BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>> + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
>> +
>> + return k->has_extra_state &&
>> + k->has_extra_state(qbus->parent);
>> +}
>> +
>> static void put_virtqueue_state(QEMUFile *f, void *pv, size_t size)
>> {
>> VirtIODevice *vdev = pv;
>> @@ -1104,6 +1114,52 @@ static const VMStateDescription vmstate_virtio_virtqueues = {
>> }
>> };
>>
>> +static int get_extra_state(QEMUFile *f, void *pv, size_t size)
>> +{
>> + VirtIODevice *vdev = pv;
>> + BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>> + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
>> + int ret = 0;
>> +
>> + ret = k->load_extra_state(qbus->parent, f);
> Should we check for ->load_extra_state() and return failure if it does
> not exist?
I think checking the existence of has_extra_state() in
virtio_extra_state_needed() is enough for this? Or is there anything I miss?
>
>> +
>> + return ret;
>> +}
>> +
>> +static void put_extra_state(QEMUFile *f, void *pv, size_t size)
>> +{
>> + VirtIODevice *vdev = pv;
>> + BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>> + VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
>> +
>> + k->save_extra_state(qbus->parent, f);
> Maybe add an assert(k->save_extra_state) here, as this means the
> transport code is buggy?
>
>> +}
>> +
>> +static VMStateInfo vmstate_info_extra_state = {
>> + .name = "virtqueue_extra_state",
>> + .get = get_extra_state,
>> + .put = put_extra_state,
>> +};
>> +
>> +static const VMStateDescription vmstate_virtio_modern_state = {
> Should probably be named "extra_state".
Right.
>
>> + .name = "virtio/extra_state",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .needed = &virtio_extra_state_needed,
>> + .fields = (VMStateField[]) {
>> + {
>> + .name = "modern_state",
> Also here.
Will fix this.
Thanks.
>> + .version_id = 0,
>> + .field_exists = NULL,
>> + .size = 0,
>> + .info = &vmstate_info_extra_state,
>> + .flags = VMS_SINGLE,
>> + .offset = 0,
>> + },
>> + VMSTATE_END_OF_LIST()
>> + }
>> +};
>> +
>> static const VMStateDescription vmstate_virtio_device_endian = {
>> .name = "virtio/device_endian",
>> .version_id = 1,
>
next prev parent reply other threads:[~2015-09-07 7:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 3:25 [Qemu-devel] [PATCH V2 0/8] virtio 1.0 pci optimizations and fixes Jason Wang
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 1/8] q35: Move options common to all classes to pc_q35_machine_options() Jason Wang
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 2/8] q35: Move options common to all classes to pc_i440fx_machine_options() Jason Wang
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 3/8] pc: Introduce pc-*-2.5 machine classes Jason Wang
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 4/8] virtio-pci: fix 1.0 virtqueue migration Jason Wang
2015-09-02 11:06 ` Cornelia Huck
2015-09-07 7:39 ` Jason Wang [this message]
2015-09-07 8:21 ` Cornelia Huck
2015-09-08 7:27 ` Jason Wang
2015-09-10 9:11 ` Michael S. Tsirkin
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 5/8] memory: don't try to adjust endianness for zero length eventfd Jason Wang
2015-09-02 15:59 ` Greg Kurz
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 6/8] virtio-pci: use wildcard mmio eventfd for 1.0 notification cap Jason Wang
2015-09-02 7:59 ` Michael S. Tsirkin
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 7/8] virtio-pci: introduce pio notification capability for modern device Jason Wang
2015-09-02 3:25 ` [Qemu-devel] [PATCH V2 8/8] virtio-pci: unbreak queue_enable read Jason Wang
2015-09-10 9:18 ` [Qemu-devel] [PATCH V2 0/8] virtio 1.0 pci optimizations and fixes Michael S. Tsirkin
2015-09-24 13:14 ` Michael S. Tsirkin
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=55ED3F4F.4060504@redhat.com \
--to=jasowang@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).