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.s...@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 kurzg...@fr.ibm.com > gk...@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.