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!
