[PATCH] system: Define ram_addr_t to be always uint64_t

[PATCH] system: Define ram_addr_t to be always uint64_t

[Peter Xu]

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.

[1] https://lore.kernel.org/r/d7b2fbf6-f9fa-4b39-8f40-95b7d5d0d8fb@oss.qualcomm.com

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@mailo.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 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) */
-#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
-- 
2.54.0

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

[Philippe Mathieu-Daudé]

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/d7b2fbf6-f9fa-4b39-8f40-95b7d5d0d8fb@oss.qualcomm.com

With the commit sha no need to link to that thread IMO.

> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Philippe Mathieu-Daudé <philmd@mailo.com>
> Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>   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é <philmd@oss.qualcomm.com>

Thanks!

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

[Peter Maydell]

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.

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

-- PMM

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

[Richard Henderson]

On 8/14/26 06: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.  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/d7b2fbf6-f9fa-4b39-8f40-95b7d5d0d8fb@oss.qualcomm.com
> 
> Cc: Paolo Bonzini<pbonzini@redhat.com>
> Cc: Philippe Mathieu-Daudé<philmd@mailo.com>
> Suggested-by: Richard Henderson<richard.henderson@linaro.org>
> Signed-off-by: Peter Xu<peterx@redhat.com>
> ---
>   include/system/ram_addr.h | 6 ------
>   1 file changed, 6 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

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

[Peter Xu]

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

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

[Peter Xu]

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/d7b2fbf6-f9fa-4b39-8f40-95b7d5d0d8fb@oss.qualcomm.com
> 
> 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 <pbonzini@redhat.com>
> > Cc: Philippe Mathieu-Daudé <philmd@mailo.com>
> > Suggested-by: Richard Henderson <richard.henderson@linaro.org>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >   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