On Mon, 27 Jan 2020 13:52:48 -0500 Collin Walling <wall...@linux.ibm.com> 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 <da...@redhat.com> 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.
