On Thu, Aug 13, 2026 at 04:51:39PM +0200, Philippe Mathieu-Daudé wrote: > On 13/8/26 16:14, Richard Henderson wrote: > > 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. > > :-)
Yep, I should have described it as allocating >4G in total, rather in one shot. So it's about the address space we can allocate that is limited.. > > > > 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. > > 🩷🩷🩷 lovely 🩷🩷🩷 I can throw a patch, just to double check one last thing: we don't support any form of 32bit hosts anymore, am I right? -- Peter Xu
