On Tue, Mar 17, 2026 at 11:27:02AM +0100, Alexander Mikhalitsyn wrote: > From: Alexander Mikhalitsyn <[email protected]> > > Add VMSTATE_VARRAY_OF_POINTER_TO_STRUCT_UINT{8, 32}_ALLOC, which > helps to save/restore a dynamic array of pointers to > structures. > > Suggested-by: Peter Xu <[email protected]> > Signed-off-by: Alexander Mikhalitsyn <[email protected]> > v2: > - added VMSTATE_VARRAY_OF_POINTER_TO_STRUCT_UINT8_ALLOC > v4: > - almost completely reworked, new flag VMS_ARRAY_OF_POINTER_ALLOW_NULL > was introduced as suggested by Peter > v5: > - rebased on top of > https://lore.kernel.org/all/[email protected]/ > --- > include/migration/vmstate.h | 77 ++++++++++++++++++++++++++++++- > migration/savevm.c | 26 +++++++++++ > migration/vmstate-types.c | 91 +++++++++++++++++++++++++++++++++++++ > migration/vmstate.c | 54 ++++++++++++++++++---- > 4 files changed, 236 insertions(+), 12 deletions(-)
Hi, Alexander, Sorry for a late reply, I didn't reply to your previous version on patch 2 because I didn't yet get time to really review this patch. It took me some time to figure out what's the best way to do this. I still think it'll be good to avoid introducing yet another info like what this patch did. In general, I want to see if we can reduce get()/put()/save()/load() rather than adding more. Meanwhile, there're small issues here and there I saw. E.g. reusing ->start to cache the object size sounds too tricky. I am trying to figure out if we can always stick with ->size to store the object size; I'll need some even pre-requisite patches though to convert some existing VMS_ARRAY_OF_POINTER users to reserve the ->size field for that, though. The other thing is I had a gut feeling this patch may have issue on the JSON blob dumped in the migration stream, via the JSONWriter* object passed into vmstate_save_vmsd_v(). All these made me feel like I'd better go prepare some RFC patches, because commenting will be too slow. I'll likely send something very soon just to show what I meant, it'll be good if you can have a look at that when it comes. Thanks, -- Peter Xu
