Re: [PULL 00/10] Next patches

[Peter Xu <peterx@redhat.com>]

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