Re: [PATCH] system: Define ram_addr_t to be always uint64_t

On Fri, 14 Aug 2026 at 14:41, Peter Xu <[email protected]> wrote:
>
> QEMU's 32bit host support was deprecated since 10.0 and removed in 11.0, at
> least the system emulation part.  Now it's safe to move ram_addr_t
> completely over to uint64_t.
>
> It should be almost the same as uintptr_t as before for !Xen, except that
> on some systems (like MacOS) uintptr_t and uint64_t can be typed slightly
> differently, causing unnecessary compiler warnings when use them in a
> mixture way.
>
> Hopefully, this change also makes it clear that ram_addr_t is never used as
> a host pointer in any form, but only an internal QEMU integer based address
> space for allocating ramblocks.

I've thought for a while that we ought to do this even if we
hadn't dropped 32-bit host support. Having ram_addr_t be
64-bit should work fine even on 32-bit hosts (as evidenced
by the fact that we forced it that way when Xen was compiled
in), it was just a performance thing to use 32-bit values here.

Having it be 32-bit sometimes was always an irritating source
of "whoops, doesn't compile on 32-bit hosts" bugs and other
oddities. There are likely various places we can clean up now
where we previously were working around this (e.g. in
hw/arm/vexpress.c:a15_daughterboard_init()).

There are also a few ifdefs on HOST_LONG_BITS == 32, which
(where they're not relevant to the tools or guest-agent)
I guess we could drop.

Reviewed-by: Peter Maydell <[email protected]>

-- PMM