On Sun, 31 May 2020 at 18:54, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > > It is pointless to have 32-bit CPUs see a 64-bit address > space, when they can only address the 32 lower bits. > > Only create CPU address space with a size it can address. > This makes HMP 'info mtree' command easier to understand > (on 32-bit CPUs).
> diff --git a/exec.c b/exec.c > index 5162f0d12f..d6809a9447 100644 > --- a/exec.c > +++ b/exec.c > @@ -2962,9 +2962,17 @@ static void tcg_commit(MemoryListener *listener) > > static void memory_map_init(void) > { > + uint64_t system_memory_size; > + > +#if TARGET_LONG_BITS >= 64 > + system_memory_size = UINT64_MAX; > +#else > + system_memory_size = 1ULL << TARGET_LONG_BITS; > +#endif TARGET_LONG_BITS is a description of the CPU's virtual address size; but the size of the system_memory memory region is related to the CPU's physical address size[*]. In particular, for the Arm Cortex-A15 (and any other 32-bit CPU with LPAE) TARGET_LONG_BITS is 32 but the CPU can address more than 32 bits of physical memory. [*] Strictly speaking, it would depend on the maximum physical address size used by any transaction master in the system -- in theory you could have a 32-bit-only CPU and a DMA controller that could be programmed with 64-bit addresses. In practice the CPU can generally address at least as much of the physical address space as any other transaction master. thanks -- PMM