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>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	dhildenb@redhat.com
Subject: Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration
Date: Fri, 19 May 2017 19:38:17 +0100	[thread overview]
Message-ID: <20170519183816.GT2081@work-vm> (raw)
In-Reply-To: <644cabb4-44ed-3b49-4c03-35b7b2266882@linux.vnet.ibm.com>

* Halil Pasic (pasic@linux.vnet.ibm.com) wrote:
> 
> 
> On 05/19/2017 07:28 PM, Dr. David Alan Gilbert wrote:
> >> To sum it up although I'm currently leaning towards abandoning my idea
> >> of two sections for two devices, I'm not comfortable with making the
> >> call myself. I'm hoping for some maintainer guidance (s390x, virtio
> >> and migration). 
> > <A couple of hours of reading, the CCW and PCI code, chatting with
> > dhildenb etc>
> > 
> > OK, so I think:
> >   a) First split the series into two separate series; one that
> > VMStatifies the existing stuff without breaking compatibility;
> > and one that adds the new stuff.  Lets get the first of those
> > going in while we think about the second.
> > 
> >     a.1) I'd do this with patches that convert one chunk into
> >      vmstate and remove the corresponding C code at the same time.
> > 
> >   b) While the way PCI devices are done is weird, I think it'll
> > be a lot simpler if you can stick to a structure that's similar
> > to them while diverging.  It's hard enough for those of us
> > who don't do Virtio every day to get our minds around virtio-pci
> > without it being different for virtio-ccw/css.
> > 
> >   c) To do (b) I suggest:
> >       c.1) you *don't* add a vmsd to your virtio_ccw_device
> > 
> >       c.2) but *do* add a VMSTATE_CCW_DEVICE to the start of any
> >          non-virtio devices you migrate (like each of the PCI devices
> >           have)
> > 
> >       c.3) You can add extra state for CSS to the ->save_extra_state
> >            handle on virtio devices or to the config
> > 
> >   d) vmstatifying the config is OK as well.
> > 
> > I should say I'm no virtio expert, so if any of that's truly
> > mad say so.
> > 
> > Dave
> > 
> 
> Agreed (a,b,c,d). Reorganizing my patch set according to a) is
> going to require some effort, but it should not be too bad. 
> About c.2): I don't think we have any migratable non virtio devices
> yet, but I'll keep it in mind.
> 
> I do not understand what you mean by c.3) and extra_sate. Maybe
> it will settle with time. My idea of extending VirtioCcwDevice
> is just adding subsections to it's VMStateDescription. The
> call vmstate_save_state(f, &vmstate_virtio_ccw_dev, dev, NULL)
> in save_config should take care of compatibility. Maybe some
> staring at virtio-pci is going to help, but right now I can't tell
> what's the extra_state for, and how/why is it 'extra'.

Yes adding extra subsections into the 'config' is probably fine;
but there's also another hook that Jason added, see a6df8adf3,
it's an existing subsection at the end of the virtio state
that can be linked for transport specific data.

Dave

> Thanks for your patience!
> 
> Regards,
> Halil
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-05-19 18:38 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
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 [this message]
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=20170519183816.GT2081@work-vm \
    --to=dgilbert@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dhildenb@redhat.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.