* Damien Hedde (damien.he...@greensocs.com) wrote: > > > On 7/24/19 6:38 PM, Dr. David Alan Gilbert wrote: > > * Philippe Mathieu-Daudé (phi...@redhat.com) 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 <damien.he...@greensocs.com> > >>> --- > >>> > >>> 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 / dgilb...@redhat.com / Manchester, UK
