All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration
Date: Mon, 8 May 2017 18:59:07 +0100	[thread overview]
Message-ID: <20170508175906.GK2120@work-vm> (raw)
In-Reply-To: <877c80d1-fa63-0fd1-e394-fb649281aea1@linux.vnet.ibm.com>

* Halil Pasic (pasic@linux.vnet.ibm.com) wrote:
> 
> 
> On 05/08/2017 07:36 PM, Dr. David Alan Gilbert wrote:
> > * Halil Pasic (pasic@linux.vnet.ibm.com) wrote:
> >> Let us use the freshly introduced vmstate migration helpers instead of
> >> saving/loading the config manually.
> >>
> >> To achieve this we need to hack the config_vector which is a common
> >> VirtIO state in the middle of the VirtioCcwDevice state representation.
> >> This somewhat ugly but we have no choice because the stream format needs
> >> to be preserved.
> >>
> >> Still no changes in behavior, but the dead code we added previously is
> >> finally awakening to life.
> >>
> >> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
> >> ---
> >> ---
> >>  hw/s390x/virtio-ccw.c | 116 +++++++++++++++++++-------------------------------
> >>  1 file changed, 44 insertions(+), 72 deletions(-)
> >>
> >> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> >> index c2badfe..8ab655c 100644
> >> --- a/hw/s390x/virtio-ccw.c
> >> +++ b/hw/s390x/virtio-ccw.c
> >> @@ -57,6 +57,32 @@ static int virtio_ccw_dev_post_load(void *opaque, int version_id)
> >>      return 0;
> >>  }
> >>  
> >> +static int get_config_vector(QEMUFile *f, void *pv, size_t size,
> >> +                             VMStateField *field)
> >> +{
> >> +    VirtioCcwDevice *dev = pv;
> >> +    VirtIODevice *vdev = virtio_bus_get_device(&dev->bus);
> >> +
> >> +    qemu_get_be16s(f, &vdev->config_vector);
> >> +    return 0;
> >> +}
> >> +
> >> +static int put_config_vector(QEMUFile *f, void *pv, size_t size,
> >> +                             VMStateField *field, QJSON *vmdesc)
> >> +{
> >> +    VirtioCcwDevice *dev = pv;
> >> +    VirtIODevice *vdev = virtio_bus_get_device(&dev->bus);
> >> +
> >> +    qemu_put_be16(f, vdev->config_vector);
> >> +    return 0;
> >> +}
> >> +
> >> +const VMStateInfo vmstate_info_config_vector = {
> >> +    .name = "config_vector",
> >> +    .get = get_config_vector,
> >> +    .put = put_config_vector,
> >> +};
> >> +
> >>  const VMStateDescription vmstate_virtio_ccw_dev = {
> >>      .name = "s390_virtio_ccw_dev",
> >>      .version_id = 1,
> >> @@ -67,6 +93,14 @@ const VMStateDescription vmstate_virtio_ccw_dev = {
> >>          VMSTATE_PTR_TO_IND_ADDR(indicators, VirtioCcwDevice),
> >>          VMSTATE_PTR_TO_IND_ADDR(indicators2, VirtioCcwDevice),
> >>          VMSTATE_PTR_TO_IND_ADDR(summary_indicator, VirtioCcwDevice),
> >> +        {
> >> +        /*
> >> +         * Ugly hack because VirtIODevice does not migrate itself.
> >> +         * This also makes legacy via vmstate_save_state possible.
> >> +         */
> >> +            .name         = "virtio/config_vector",
> >> +            .info         = &vmstate_info_config_vector,
> >> +        },
> > 
> > I'm a bit confused - isn't just this bit the bit going
> > through the vdev->load_config hook?
> > 
> 
> Exactly! If you examine the part underscored with ============== in
> virtio_ccw_(load|save)_config  (that is what is behind vdev->load_config)
> you should see that we use vmstate_virtio_ccw_dev (that is this
> VMStateDescription to implement these function. 
> 
> Actually virtio_ccw_(load|save)_config won't do anything after patch 9
> and for new machines since the VirtIOCcwDevice is going to migrate
> itself via DeviceClass.vmsd like other "normal" devices, and we fall
> back to the VirtIO specific callbacks only in "legacy mode".
> 
> I hope this helps!

Hmm, still confused!
Why are you changing a Virtio device not to use the same migration
oddities as all the other virtio devices?

I was assuming we'd have to change the virtio core code to
solve that for all virtio devices.

Dave

> Halil
> 
> 
> > 
> >>          VMSTATE_STRUCT(routes, VirtioCcwDevice, 1, vmstate_adapter_routes, \
> >>                         AdapterRoutes),
> >>          VMSTATE_UINT8(thinint_isc, VirtioCcwDevice),
> >> @@ -1272,85 +1306,23 @@ static int virtio_ccw_load_queue(DeviceState *d, int n, QEMUFile *f)
> >>  static void virtio_ccw_save_config(DeviceState *d, QEMUFile *f)
> >>  {
> >>      VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
> >> -    CcwDevice *ccw_dev = CCW_DEVICE(d);
> >> -    SubchDev *s = ccw_dev->sch;
> >> -    VirtIODevice *vdev = virtio_ccw_get_vdev(s);
> >>  
> >> -    subch_device_save(s, f);
> >> -    if (dev->indicators != NULL) {
> >> -        qemu_put_be32(f, dev->indicators->len);
> >> -        qemu_put_be64(f, dev->indicators->addr);
> >> -    } else {
> >> -        qemu_put_be32(f, 0);
> >> -        qemu_put_be64(f, 0UL);
> >> -    }
> >> -    if (dev->indicators2 != NULL) {
> >> -        qemu_put_be32(f, dev->indicators2->len);
> >> -        qemu_put_be64(f, dev->indicators2->addr);
> >> -    } else {
> >> -        qemu_put_be32(f, 0);
> >> -        qemu_put_be64(f, 0UL);
> >> -    }
> >> -    if (dev->summary_indicator != NULL) {
> >> -        qemu_put_be32(f, dev->summary_indicator->len);
> >> -        qemu_put_be64(f, dev->summary_indicator->addr);
> >> -    } else {
> >> -        qemu_put_be32(f, 0);
> >> -        qemu_put_be64(f, 0UL);
> >> -    }
> >> -    qemu_put_be16(f, vdev->config_vector);
> >> -    qemu_put_be64(f, dev->routes.adapter.ind_offset);
> >> -    qemu_put_byte(f, dev->thinint_isc);
> >> -    qemu_put_be32(f, dev->revision);
> >> +    /*
> >> +     * We save in legacy mode. The components take care of their own
> >> +     * compat. representation (based on css_migration_enabled).
> >> +     */
> >> +    vmstate_save_state(f, &vmstate_virtio_ccw_dev, dev, NULL);
> ====================================================================
>    
> >>  }
> >>  
> >>  static int virtio_ccw_load_config(DeviceState *d, QEMUFile *f)
> >>  {
> >>      VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
> >> -    CcwDevice *ccw_dev = CCW_DEVICE(d);
> >> -    CCWDeviceClass *ck = CCW_DEVICE_GET_CLASS(ccw_dev);
> >> -    SubchDev *s = ccw_dev->sch;
> >> -    VirtIODevice *vdev = virtio_ccw_get_vdev(s);
> >> -    int len;
> >> -
> >> -    s->driver_data = dev;
> >> -    subch_device_load(s, f);
> >> -    /* Re-fill subch_id after loading the subchannel states.*/
> >> -    if (ck->refill_ids) {
> >> -        ck->refill_ids(ccw_dev);
> >> -    }
> >> -    len = qemu_get_be32(f);
> >> -    if (len != 0) {
> >> -        dev->indicators = get_indicator(qemu_get_be64(f), len);
> >> -    } else {
> >> -        qemu_get_be64(f);
> >> -        dev->indicators = NULL;
> >> -    }
> >> -    len = qemu_get_be32(f);
> >> -    if (len != 0) {
> >> -        dev->indicators2 = get_indicator(qemu_get_be64(f), len);
> >> -    } else {
> >> -        qemu_get_be64(f);
> >> -        dev->indicators2 = NULL;
> >> -    }
> >> -    len = qemu_get_be32(f);
> >> -    if (len != 0) {
> >> -        dev->summary_indicator = get_indicator(qemu_get_be64(f), len);
> >> -    } else {
> >> -        qemu_get_be64(f);
> >> -        dev->summary_indicator = NULL;
> >> -    }
> >> -    qemu_get_be16s(f, &vdev->config_vector);
> >> -    dev->routes.adapter.ind_offset = qemu_get_be64(f);
> >> -    dev->thinint_isc = qemu_get_byte(f);
> >> -    dev->revision = qemu_get_be32(f);
> >> -    if (s->thinint_active) {
> >> -        dev->routes.adapter.adapter_id = css_get_adapter_id(
> >> -                                         CSS_IO_ADAPTER_VIRTIO,
> >> -                                         dev->thinint_isc);
> >> -    }
> >>  
> >> -    return 0;
> >> +    /*
> >> +     * We load in legacy mode. The components take take care to read
> >> +     * only stuff which is actually there (based on css_migration_enabled).
> >> +     */
> >> +    return vmstate_load_state(f, &vmstate_virtio_ccw_dev, dev, 1);
> ========================================================================
> 
> >>  }
> >>  
> >>  static void virtio_ccw_pre_plugged(DeviceState *d, Error **errp)
> >> -- 
> >> 2.10.2
> >>
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-05-08 17:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 17:34 [Qemu-devel] [PATCH 00/10] migration: s390x css migration Halil Pasic
2017-05-05 17:34 ` [Qemu-devel] [PATCH 01/10] s390x: add helper get_machine_class Halil Pasic
2017-05-05 17:34 ` [Qemu-devel] [PATCH 02/10] s390x: add css_migration_enabled to machine class Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 03/10] s390x/css: add vmstate entities for css Halil Pasic
2017-05-08 16:45   ` Dr. David Alan Gilbert
2017-05-09 12:00     ` Halil Pasic
2017-05-15 18:01       ` Dr. David Alan Gilbert
2017-05-18 14:15         ` Halil Pasic
2017-05-19 14:55           ` Dr. David Alan Gilbert
2017-05-19 15:08             ` Halil Pasic
2017-05-19 16:00             ` Halil Pasic
2017-05-19 17:43               ` Dr. David Alan Gilbert
2017-05-19 16:33             ` Halil Pasic
2017-05-19 17:47               ` Dr. David Alan Gilbert
2017-05-19 18:04                 ` Halil Pasic
2017-05-09 12:20     ` Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 04/10] s390x/css: add vmstate macro for CcwDevice Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 05/10] virtio-ccw: add vmstate entities for VirtioCcwDevice Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration Halil Pasic
2017-05-08 16:55   ` Dr. David Alan Gilbert
2017-05-09 17:05     ` Halil Pasic
2017-05-10 10:31       ` Dr. David Alan Gilbert
2017-05-10 10:38       ` Cornelia Huck
2017-05-08 17:36   ` Dr. David Alan Gilbert
2017-05-08 17:53     ` Halil Pasic
2017-05-08 17:59       ` Dr. David Alan Gilbert [this message]
2017-05-08 18:27         ` Halil Pasic
2017-05-08 18:42           ` Dr. David Alan Gilbert
2017-05-10 11:52             ` Halil Pasic
2017-05-15 19:07               ` Dr. David Alan Gilbert
2017-05-16 22:05                 ` Halil Pasic
2017-05-19 17:28                   ` Dr. David Alan Gilbert
2017-05-19 18:02                     ` Halil Pasic
2017-05-19 18:38                       ` Dr. David Alan Gilbert
2017-05-05 17:35 ` [Qemu-devel] [PATCH 07/10] s390x/css: remove unused subch_dev_(load|save) Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 08/10] s390x/css: add ORB to SubchDev Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 09/10] s390x/css: turn on channel subsystem migration Halil Pasic
2017-05-08 17:27   ` Dr. David Alan Gilbert
2017-05-08 18:03     ` Halil Pasic
2017-05-08 18:37       ` Dr. David Alan Gilbert
2017-05-09 17:27         ` Halil Pasic
2017-05-05 17:35 ` [Qemu-devel] [PATCH 10/10] s390x/css: use SubchDev.orb Halil Pasic

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=20170508175906.GK2120@work-vm \
    --to=dgilbert@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.