On Fri, Aug 14, 2026 at 04:26:39PM +0200, Philippe Mathieu-Daudé wrote: > On 2026-08-14 15:40, Peter Xu wrote: > > QEMU's 32bit host support was deprecated since 10.0 and removed in 11.0, at > > least the system emulation part > > (see commit 372ec46b9f "meson: Reject 32-bit hosts")
The "at least the system emulation part" was almost for cf634dfcd8f that we re-enabled tools for 32bits. I'll reference both commit IDs when repost. > > . 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. > > > > [1] > > https://lore.kernel.org/r/[email protected] > > With the commit sha no need to link to that thread IMO. I wish to keep this to provide a reference to the MacOS issue I mentioned. > > > > > Cc: Paolo Bonzini <[email protected]> > > Cc: Philippe Mathieu-Daudé <[email protected]> > > Suggested-by: Richard Henderson <[email protected]> > > Signed-off-by: Peter Xu <[email protected]> > > --- > > include/system/ram_addr.h | 6 ------ > > 1 file changed, 6 deletions(-) > > > > diff --git a/include/system/ram_addr.h b/include/system/ram_addr.h > > index 129f6b8757..06caca1506 100644 > > --- a/include/system/ram_addr.h > > +++ b/include/system/ram_addr.h > > @@ -15,15 +15,9 @@ > > #define RAM_ADDR_H > > /* address in the RAM (different from a physical address) */ > > While here we could describe a bit more: > > /* > * ram_addr_t - Offset in QEMU's internal RAM address space (not a guest > physical address). > */ Sure! -- Peter Xu
