Re: [PATCH 0/4] migration: Remove extra type-checking from vmstate macros

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> On Wed, Jul 29, 2026 at 07:52:23PM -0300, Fabiano Rosas wrote:
>> Hi, this is basically what I ranted about in:
>> https://lore.kernel.org/r/87jyqeomqz.fsf@suse.de
>> 
>> I'm replacing the per-integer-size type checks with a single "int that
>> fits in 32bit" check. This allows several lines of duplicated code to
>> be removed.
>> 
>> I haven't changed the macro names in the device code yet. If this
>> series gets positive feedback then I'll send per-subsystem patches
>> doing that.
>> 
>> CI run: https://gitlab.com/farosas/qemu/-/pipelines/2716814081
>> Also tested:
>> - migration-test --full --thorough
>> - x86_64 compat run forwards and backwards for previous 3 QEMU releases
>> - s390x compat run forwards and backwards for previous 2 QEMU releases
>> - ppc64 compat run forwards and backwards for previous QEMU release
>> - migration-test smoke ASAN/UBSAN run
>> 
>> Fabiano Rosas (4):
>>   migration: Remove VMSTATE_ARRAY_INT32_UNSAFE
>>   migration: Introduce VMStateOffset
>>   migration: Remove redundant flags
>>   migration: Remove duplicate vmstate macros
>
> Nice work!
>
> I think I was only looking at VBUFFER side and I thought it was fine
> sticking with 32bit even signed or not, not a huge deal.  But cleaning up
> VARRAY whole thing together looks definitely an improvement.  I definitely
> like your version here.
>
> I assume with your series I can drop both of my patches here, right?
>
>   [PATCH v2 1/5] migration: Fix possible overflow in vmstate_handle_alloc()
>   https://lore.kernel.org/r/20260728210417.1925078-2-peterx@redhat.com
>   (I'll still respin with the rest)
>
>   [PATCH] vhost/migration: Fix incorrect size used in inflight->addr in VMSD
>   https://lore.kernel.org/r/20260728153942.1891677-1-peterx@redhat.com
>
> The only missing piece would be an multiply overflow check in
> vmstate_handle_alloc(), if you could add that check too while rewritting
> that in patch 1 then I think it'll cover all.
>
> Vladimir's ask in the separate email makes sense: I wonder if we can also
> do one step further and merge VBUFFER into VARRAY.
>
> The other trivial thing is, while looking, I found one trivial macro
> VMSTATE_PARTIAL_VBUFFER not used; can drop it altogether.

I can look at it all. Just a heads-up, I'll be off for a couple of weeks
starting tomorrow.