On Mon, 15 May 2017 18:09:04 +0200
Cédric Le Goater <clg@kaod.org> wrote:

> On 05/15/2017 03:16 PM, Greg Kurz wrote:
> > On Mon, 15 May 2017 14:22:32 +0200
> > Cédric Le Goater <clg@kaod.org> wrote:
> >   
> >> On 05/15/2017 01:40 PM, Greg Kurz wrote:  
> >>> Commit 5bc8d26de20c ("spapr: allocate the ICPState object from under
> >>> sPAPRCPUCore") moved ICP objects from the machine to CPU cores. This
> >>> is an improvement since we no longer allocate ICP objects that will
> >>> never be used. But it has the side-effect of breaking migration of
> >>> older machine types from older QEMU versions.
> >>>
> >>> This patch introduces a compat flag in the sPAPR machine class so
> >>> that all pseries machine up to 2.9 go on with the previous behavior
> >>> of pre-allocating ICP objects.    
> >>
> >> I think this is a quite elegant way to a handle the migration 
> >> regression. Thanks for taking care of it.
> >>
> >> Have you tried to simply reparent the ICPs objects to OBJECT(spapr) 
> >> instead of the OBJECT(cpu)  ? 
> >>  
> > 
> > Do you mean to reparent unconditionally to OBJECT(spapr) for all
> > machine versions ?   
> 
> only in the case of smc->must_pre_allocate_icps
> 
> > I'm not sure this would be beneficial, but I might be missing 
> > something...  
> 
> I think that we would not need to allocate the legacy_icps array. 
> Parenting the icp object to the spapr machine should be enough. 
> I might be wrong. my expertise on the migration stream is very 
> basic.
> 

I don't think this would work because an older QEMU would still
send state for objects that don't exist in the destination.

> C.
>