Re: [PULL 00/10] Next patches

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.  :-)
> 
> 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 🩷🩷🩷