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

[Peter Xu <peterx@redhat.com>]

On Fri, Aug 14, 2026 at 03:48:32PM +0100, Peter Maydell wrote:
> On Fri, 14 Aug 2026 at 14:41, Peter Xu <peterx@redhat.com> 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.

Indeed.  Let me see whether I can touch those in one go.

> 
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

Thanks,

-- 
Peter Xu