Re: [PATCH v6 2/2] s390: diagnose 318 info reset and migration support

[Cornelia Huck]

On Mon, 27 Jan 2020 13:52:48 -0500
Collin Walling <address@hidden> wrote:

> On 1/27/20 1:21 PM, Collin Walling wrote:
> > On 1/27/20 12:55 PM, David Hildenbrand wrote:  
> >> On 27.01.20 18:29, Cornelia Huck wrote:  
> >>> On Mon, 27 Jan 2020 18:09:11 +0100
> >>> David Hildenbrand <address@hidden> wrote:

> >>>> ... I actually thought we have something like this already. Personally,
> >>>> I think that would make sense. At least spapr seems to have something
> >>>> like this already (hw/ppc/spapr.c:spapr_machine_init().
> >>>>
> >>>> @Conny?  
> >>>
> >>> What are you referring to? I only see the one with the FIXME in front
> >>> of it...  
> >>
> >> That's the one I mean. The fixme states something about qdev ... but
> >> AFAIK that's only applicable if TYPE_DEVICE is involved. So maybe right
> >> now there is no other way than registering the vmstate directly.
> >>  
> > 
> > Hmm okay. I'll take a look at how spapr does it. I think I've registered a
> > vmstate via register_savevm_live() in an earlier version, but had 
> > difficulties
> > figuring out where to store the data. I'll revisit this approach.
> > 
> > Thanks for the feedback!
> >   
> 
> Err perhaps not entirely in this manner...
> 
> docs/devel/migration.rst declares the register_savevm_live() function as the
> "legacy way" of doing things. I'll have to see how other VMStateDescriptions
> are modeled. I think vmstate_register() is what I want.
> 
> Sorry for the confusion.

Ok, I've now read what the FIXME actually says :) Since the machine
does not inherit from device (but from object), vmstate_register()
looks like the right thing to do.