On Wed, Jul 29, 2026 at 01:13:27PM -0300, Fabiano Rosas wrote: > Peter Xu <[email protected]> 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
