Re: [PULL 00/10] Next patches

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~