Re: [PATCH 5/6] exec: Restrict 32-bit CPUs to 32-bit address space

[Philippe Mathieu-Daudé]

On 5/31/20 9:09 PM, Peter Maydell wrote:
> On Sun, 31 May 2020 at 18:54, Philippe Mathieu-Daudé <f4bug@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[*].

OK I misunderstood it was the physical size, not virtual.

> 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.

Yes, I tried the Malta with 32-bit core, while the GT64120 northbridge
addresses 64-bit:

address-space: cpu-memory-0
  0000000000000000-00000000ffffffff (prio 0, i/o): system
    0000000000000000-0000000007ffffff (prio 0, ram): alias
mips_malta_low_preio.ram @mips_malta.ram 0000000000000000-0000000007ffffff
    0000000000000000-000000001fffffff (prio 0, i/o): empty-slot
    0000000010000000-0000000011ffffff (prio 0, i/o): alias pci0-io @io
0000000000000000-0000000001ffffff
    0000000012000000-0000000013ffffff (prio 0, i/o): alias pci0-mem0
@pci0-mem 0000000012000000-0000000013ffffff

address-space: gt64120_pci
  0000000000000000-ffffffffffffffff (prio 0, i/o): bus master container
    0000000000000000-00000000ffffffff (prio 0, i/o): alias bus master
@system 0000000000000000-00000000ffffffff [disabled]

So my testing is bad, because I want @system to be 64-bit wide for the
GT64120.

>From "In practice the CPU can generally address at least as much of the
physical address space as any other transaction master." I understand
for QEMU @system address space must be as big as the largest transaction
a bus master can do".

I think what confuse me is what QEMU means by 'system-memory', I
understand it historically as the address space of the first CPU core.

This is more complex in the case of the raspi SoC where the DSP can
address the main bus (system memory) while the ARM cores access it via
an MMU, see this schema:
https://www.raspberrypi.org/forums/viewtopic.php?t=262747

Regards,

Phil.