qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] [PATCH for 4.1?] pl330: fix vmstate descript


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH for 4.1?] pl330: fix vmstate description
Date: Thu, 25 Jul 2019 09:16:12 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

* Damien Hedde (address@hidden) wrote:
> 
> 
> On 7/24/19 6:38 PM, Dr. David Alan Gilbert wrote:
> > * Philippe Mathieu-Daudé (address@hidden) wrote:
> >> On 7/24/19 4:35 PM, Damien Hedde wrote:
> >>> Fix the pl330 main and queue vmstate description.
> >>> There were missing POINTER flags causing crashes during
> >>> incoming migration because:
> >>> + PL330State chan field is a pointer to an array
> >>> + PL330Queue queue field is a pointer to an array
> >>>
> >>> Also bump corresponding vmsd version numbers.
> >>>
> >>> Signed-off-by: Damien Hedde <address@hidden>
> >>> ---
> >>>
> >>> I found this while working on reset with xilinx-zynq machine.
> >>>
> >>> I'm not sure what's the vmsd version policy in such cases (for
> >>> backward compatibility). I've simply bumped them since migration
> >>> was not working anyway (vmstate_load_state was erasing critical part
> >>> of PL330State and causing segfaults while loading following fields).
> >>
> >> I still not understand versioning and migration
> > 
> > Incrementing the version (and minimum) is the right thing
> > to do if you conclude the old one was hopelessly broken.
> > Migration to and from old qemu breaks, but who cares since it was toast
> > anyway.
> > As far as I can tell pl330 is only on our zynq and exynos models
> > so wont break our versioned 'virt' type.
> > So from a migration point of view:
> 
> Since switching from VARRAY to VARRAY_POINTER does not change the size
> of what's migrated, it should be possible to accept migration from old
> qemu if we can ignore the data in such cases and default to something
> (but what ? put the pl330 in reset state ?)

I don't think it's worth worrying about doing that unless you need to
preserve migration compatibility - which is less important for
stuff where it's used for dev rather than VMs


Dave

> Thanks,
> Damien
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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