Re: [Qemu-ppc] [PATCH 23/25] PPC: e500: dt: use target_phys_addr_t for ramsize

[Scott Wood]

On 05/31/2012 05:39 PM, Alexander Graf wrote:
> 
> On 01.06.2012, at 00:24, Scott Wood wrote:
> 
>> On 05/31/2012 05:18 PM, Alexander Graf wrote:
>>>
>>> On 01.06.2012, at 00:07, Scott Wood wrote:
>>>
>>>> On 05/30/2012 06:00 AM, Alexander Graf wrote:
>>>>> We're passing the ram size as uint32_t, capping it to 32 bits atm.
>>>>> Change to target_phys_addr_t (uint64_t) to make sure we have all
>>>>> the bits.
>>>>
>>>> Wouldn't ram_addr_t be more appropriate?
>>>
>>> I never quite grasped the difference, but wasn't ram_addr_t something for 
>>> the host?
>>
>> I don't fully understand QEMU's RAM handling, but from what I recall RAM
>> is treated differently from arbitrary guest physical addresses, with a
>> QEMU-internal contiguous address space.  Guest RAM needs to be mappable
>> by QEMU as well as the target, so ram_addr_t is 32-bit on a 32-bit host,
>> even if target_phys_addr_t is different.
>>
>> But again, it was a while ago that I looked at this, and I didn't fully
>> understand it then, so I may be missing or misremembering something.
> 
> Right, so target_phys_addr_t is what we want, because that's what
> describes the guest's physical memory layout the best, which is what
> we're describing here, right? It should definitely be independent of
> the host's virtual memory layout.

It's not really the host virtual memory layout -- it's just constrained
by the need to fit there.  QEMU's notion of a "RAM address" is a
different address space than either target physical or host virtual.  We
can't have more target RAM than will fit in ram_addr_t (though it can
start at a target physical address that doesn't fit in ram_addr_t).

If you want to use target_phys_addr_t here, fine -- it's not performance
critical -- but the uint32_t was only really removing a limitation on
64-bit hosts, and semanticly target_phys_addr_t doesn't seem as correct
as ram_addr_t.

The same applies to initrd_size, which currently uses target_phys_addr_t.

If we were discussing the address of RAM (as seen by the target), rather
than the size of it, then target_phys_addr_t would be correct (and we
already use it for that).

>From HACKING:
"Use target_phys_addr_t for guest physical addresses except pcibus_t
for PCI addresses.  In addition, ram_addr_t is a QEMU internal address
space that maps guest RAM physical addresses into an intermediate
address space that can map to host virtual address spaces.  Generally
speaking, the size of guest memory can always fit into ram_addr_t but
it would not be correct to store an actual guest physical address in a
ram_addr_t."

-Scott