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/[email protected] 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) */ -#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
