On Fri, Aug 14, 2026 at 03:48:32PM +0100, Peter Maydell wrote: > 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.
Indeed. Let me see whether I can touch those in one go. > > Reviewed-by: Peter Maydell <[email protected]> Thanks, -- Peter Xu
