Re: [PATCH] vhost/migration: Fix incorrect size used in inflight->addr in VMSD

[Peter Xu <peterx@redhat.com>]

On Wed, Jul 29, 2026 at 01:13:27PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
> 
> > On Wed, Jul 29, 2026 at 11:27:44AM -0300, Fabiano Rosas wrote:
> >> Hm, but isn't it better to have a global cap anyway? So we don't need
> >> every device code to change with similar checks.
> >> 
> >> > If we go this route, I'd rather merge Michael's version to support u64,
> >> > even if we don't need a u64 size.  But I really don't want to introduce yet
> >> > another VMS flag just for this... we'll have no real use if we have noticed
> >> > this problem when the vhost inflight patch was reviewed.  It will be a
> >> > uint32_t or int32_t already.  I just can't come up with some users need
> >> > size >2G.
> >> >
> >> 
> >> I agree with making all u64. I think we can actually remove all the
> >> extra VMS_VARRAY_* and VBUFFER_* flags and instead doa single type-check
> >> of "int <= 64bit". Give me a couple of hours and I will post an RFC.
> >
> > I confess I don't yet get what is the global cap you mentioned.. but sure,
> > I'll wait and read the RFC first.
> 
> I was thinking the vmstate code could define a limit to the size (of
> anything) and always enforce it. The device code can then use some
> custom macros (not yet existent) to limit even further.

Ah I see.

With 32bit limit (let's assume we don't have that further "it's int32_t"
problem..), it's already throttled to 32bit max.  I added it into vhost
code only because in reality it was a 64bit internally.  None of the rest
users should need it since they should be sticking with 32bit fields.

-- 
Peter Xu