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
