* Jean-Philippe Brucker (jean-phili...@linaro.org) wrote:
> On Wed, Feb 02, 2022 at 02:21:37PM +0100, Eric Auger wrote:
> > >>> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c
> > >>> index ec02029bb6..a112428c65 100644
> > >>> --- a/hw/virtio/virtio-iommu.c
> > >>> +++ b/hw/virtio/virtio-iommu.c
> > >>> @@ -43,6 +43,7 @@
> > >>>
> > >>> typedef struct VirtIOIOMMUDomain {
> > >>> uint32_t id;
> > >>> + bool bypass;
> > >> I am afraid this will break the migration if you don't change
> > >> vmstate_domain.
> > >>
> > >> See static const VMStateDescription vmstate_domain.
> > >> Also you need to migrate the new bypass field.
> > >>
> > >> Logically we should handle this with a vmstate subsection I think to
> > >> handle migration of older devices. However I doubt the device has been
> > >> used in production environment supporting migration so my guess is we
> > >> may skip that burden and just add the missing field. Adding Juan, Dave &
> > >> Peter for advices.
> > > I'm not sure about users of this; if no one has used it then yeh; you
> > > could bump up the version_id to make it a bit clearer.
> >
> > Thank you for your input. Yes to me it sounds OK to only bump the
> > version_id while adding the new field.
>
> Ok. Just to make sure we're on the same page, this means we don't support
> migration from new->old or old->new instances, since the migration stream
> doesn't carry a version ID for the virtio-iommu-device and domain
> vmstates, as far as I understand. I also believe backward-incompatible
> changes are fine this time around, though I don't have much visibility in
> what's being used.
I think the stream only has it for top level devices; I've not dug into
this device.
Dave
> Thanks,
> Jean
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
