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

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")
>.  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.

> 
> 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).
  */

> -#if defined(CONFIG_XEN_BACKEND)
>   typedef uint64_t ram_addr_t;
>   #  define RAM_ADDR_MAX UINT64_MAX
>   #  define RAM_ADDR_FMT "%" PRIx64
> -#else
> -typedef uintptr_t ram_addr_t;
> -#  define RAM_ADDR_MAX UINTPTR_MAX
> -#  define RAM_ADDR_FMT "%" PRIxPTR
> -#endif
>   
>   #define DIRTY_MEMORY_VGA       0
>   #define DIRTY_MEMORY_CODE      1

Reviewed-by: Philippe Mathieu-Daudé <[email protected]>

Thanks!