On Mon, 9 Feb 2026 at 15:08, Alex Bennée <[email protected]> wrote:
>
> Eric Auger <[email protected]> writes:

> > +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
> > +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> > +    int32_t cpreg_vmstate_missing_indexes_array_len;
> > +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> > +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
> > +
>
> This seems a bit old school when we have GArray.

> > +    int arraylen = cpu->cpreg_vmstate_array_len + 
> > MAX_CPREG_VMSTATE_ANOMALIES;
> >
> > +    cpu->cpreg_vmstate_indexes = g_renew(uint64_t, 
> > cpu->cpreg_vmstate_indexes,
> > +                                         arraylen);
> > +    cpu->cpreg_vmstate_values = g_renew(uint64_t, 
> > cpu->cpreg_vmstate_values,
> > +                                        arraylen);
> > +    cpu->cpreg_vmstate_array_len = arraylen;
>
> I wonder if these would be candidates for fixing up as well.

These ones are the types they are because they need to match
what VMSTATE_VARRAY_INT32() expects -- these are the data
that goes out on the migration stream.

-- PMM

Reply via email to