[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 07/33] serial: register vmsd with DeviceClass

From: Peter Maydell
Subject: Re: [PATCH v3 07/33] serial: register vmsd with DeviceClass
Date: Tue, 19 Nov 2019 10:33:24 +0000

On Tue, 19 Nov 2019 at 10:23, Marc-André Lureau
<address@hidden> wrote:
> On Mon, Nov 18, 2019 at 6:22 PM Peter Maydell <address@hidden> wrote:
> > Did you test whether migration still works from a QEMU
> > version without this patch to one with it? (The migration
> Yes, I thought I did test correctly, but I realized testing with x86
> isn't correct.
> So with arm/musicpal for ex, I can migrate from before->after, however
> after->before won't work. Is that ok?

Broadly speaking, the only case where we care about not
breaking cross-version migration is where we have a versioned
machine type. So musicpal doesn't matter too much. Beyond
that, yes, generally before->after is more important than
after->before. I have a feeling Red Hat downstream cares about
after->before migration at least for x86 but you or your colleagues
would know that better than me :-)

> > vmstate code is too complicated for me to be able to figure
> > out whether passing the 'dev' pointer makes a difference
> > to whot it names the state sections and whether the
> > 'qdev_set_legacy_instance_id' suffices to avoid problems.)
> I don't see a way to fix after->before, because the instance id is
> initially 0 with the new code, and the old code expect a different
> value.

Can you explain how the instance ID stuff works? I was
expecting that the result of setting the legacy instance ID
would just be that the new version would always have
the older setting, so if it works for old->new it would also
work for new->old. But as I say I don't understand this bit
of the migration code.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]