Re: [Qemu-devel] [PATCH RFC 1/8] virtio: add subsections to the migration stream

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, May 15, 2014 at 09:04:49AM +0200, Greg Kurz wrote:
> On Thu, 15 May 2014 12:16:35 +0530
> Amit Shah <amit.shah@redhat.com> wrote:
> > On (Thu) 15 May 2014 [09:23:51], Michael S. Tsirkin wrote:
> > > On Thu, May 15, 2014 at 11:34:25AM +0530, Amit Shah wrote:
> > > > On (Wed) 14 May 2014 [17:41:38], Greg Kurz wrote:
> > > > > There is a need to add some more fields to VirtIODevice that should be
> > > > > migrated (broken status, endianness). The problem is that we do not
> > > > > want to break compatibility while adding a new feature... This issue has
> > > > > been addressed in the generic VMState code with the use of optional
> > > > > subsections. As a *temporary* alternative to port the whole virtio
> > > > > migration code to VMState, this patch mimics a similar subsectionning
> > > > > ability for virtio.
> > 
> > BTW Greg, do you plan on working on vmstate for virtio?
> > 
> 
> Yes.
> 
> > > > > Since each virtio device is streamed in its own section, the idea is to
> > > > > stream subsections between the end of the device section and the start
> > > > > of the next sections. This allows an older QEMU to complain and exit
> > > > > when fed with subsections:
> > > > > 
> > > > > Unknown savevm section type 5
> > > > > Error -22 while loading VM state
> > > > 
> > > > Please make this configurable -- either via configure or device
> > > > properties.  That avoids having to break existing configurations that
> > > > work without this patch.
> > > > 
> > > > > All users of virtio_load()/virtio_save() need to be patched because the
> > > > > subsections are streamed AFTER the device itself.
> > > > 
> > > > Since all have the same fixup, I'm wondering if a new section can be
> > > > added to the virtio-bus itself, which gets propagated to all devices
> > > > upon load in the dest.
> > > 
> > > This calls for a way for devices to inherit properties from the bus,
> > > which doesn't exist ATM.
> > > Fine but let's not hold up this patchset because of this.
> > 
> > No, only suggestion is to add a migration section in the bus, and then
> > it's easier to do this in the post-migrate functions for each device
> > -- so only one new section gets introduced instead of all devices
> > being modified to send a new subsection.
> > 
> 
> The main problem I see is that virtio sucks: as you see in patch 8, we have
> to be careful not to call vring or virtqueue stuff before the device knows
> its endianness or it breaks...

I see.
I think it's all not a big deal.
People here suggested many ways to deal with it, but IMHO the
only thing that does matter is the functionality.

Functionality-wise I think the only two things that were mentioned were
- decent chance that migration to a wrong machine
  version fails gracefully
- migrate in a compatible way with correct legacy machine version

> I need to study how the virtio-bus gets
> migrated to ensure the endian section is streamed before the devices.
> 
> > 		Amit
> > 
> 
> Thanks.
> 
> -- 
> Gregory Kurz                                     kurzgreg@fr.ibm.com
>                                                  gkurz@linux.vnet.ibm.com
> Software Engineer @ IBM/Meiosys                  http://www.ibm.com
> Tel +33 (0)562 165 496
> 
> "Anarchy is about taking complete responsibility for yourself."
>         Alan Moore.