On 8/13/26 06:41, Peter Xu wrote:
Now when I think about it from the root, I tend to like what Xen defines
with ram_addr_t:
/* 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
I don't know how we supported 32bit host emulating anything larger, but
logically it's doable, then IIUC uintptr_t won't be enough allocating
anything >4G?
ram_addr_t != hwaddr or vaddr -- it's just an internal token.
So a 32-bit machine could put 1G of ram (identified by ram_addr_t) at 8G (hwaddr) just
fine. But obviously it couldn't put 8G of ram anywhere. :-)
That said, Xen was weird in that it used to be possible to have an i386 qemu command-line
talking to a x86_64 dom0 kernel controlling x86_64 guests.
So, yeah, now we should drop this ram_addr_t distinction and always use
uint64_t.
r~
