On Fri, 16 May 2014 17:40:00 +0800
Fam Zheng <f...@redhat.com> wrote:
> On Fri, 05/16 11:22, Andreas Färber wrote:
> > Am 16.05.2014 11:14, schrieb Fam Zheng:
> > > On Thu, 05/15 12:08, Greg Kurz wrote:
> > >>>> 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 need to study how the virtio-bus gets
> > >>>> migrated to ensure the endian section is streamed before the devices.
> > >>>
> > >>> There is no ordering guarantee. The state needs to be migrated in the
> > >>> device or bus where it sits, if post-load processing is required; i.e.,
> > >>> if it's in VirtIODevice then something like this series, if it were on
> > >>> VirtioBus exclusively (device asking bus for its endianness each time
> > >>> and does not do post-load stuff) then endianness could be migrated as a
> > >>> new bus section. Not sure if that would help the "broken" state though?
> > >>>
> > >>
> > >> IIRW the "broken" state was proposed as a per-device property...
> > >
> > > Yes.
> >
> > Sure, and that makes sense, but we do have a 1:1 relation of bus/device,
> > or does virtio-mmio support more? If device doesn't work for some
> > reason, we could (mis)use the bus as fallback then.
> >
>
> FWIW, I just realized that "broken" may be loaded from device status bit in
> the
> future, so we don't need to migrate the field separately:
>
> https://tools.oasis-open.org/issues/browse/VIRTIO-98
>
> Fam
>
Oh, if you are targetting virtio 1.0... all the virtio endian stuff I am
working on is for legacy virtio. Unless you plan to do something for
legacy, I guess our objectives differ.
Cheers.
--
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.
