Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t

[Peter Maydell <peter.maydell@linaro.org>]

On 3 September 2011 12:26, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani <Ani.Sinha@tellabs.com> wrote:
>> First off, what is the difference between target_phys_addr_t and
>> ram_addr_t? I believe the former is a virtual address within the guest but
>> what is the later? The comment says "address in ram (different from
>> physical address)" but is this the virtual address or the physical
>> address? Is this for guest or for host?
>
> target_phys_addr_t is used for guest physical addresses. For example,
> i386 guest with PAE would need 36 bits which makes this 64 bit type
> (regardless of host address sizes). Devices should usually only use
> this type.
>
> ram_addr_t (uintptr_t) is linked to the size of host virtual address
> space. Because of how RAM is implemented, we can't give 64 bit guests
> more than 4 GB of RAM on a 32 bit host, so in that case it would be 32
> bits. On a 64 bit host this can be 64 bits. It can be considered as a
> subset of target_phys_addr_t. Normally devices need it only if there
> are RAM areas, like frame buffers.

To add to this and point out some particular wrinkles:
Even if on the guest machine RAM doesn't start at physical address
0, the first bit of RAM will generally be at a zero ram_addr_t.
If the guest machine has some RAM that is mapped at two physical
addresses, then both those target_phys_addr_t values will map to
the same ram_addr_t. This is why you can't just cast a ram_addr_t
to a target_phys_addr_t or vice-versa. (This kind of situation
doesn't happen on the PC but does on some of the embedded boards
qemu models.)

I think of ram_addr_t as being "offset into a big lump of host
memory which we have parcelled out to use as guest RAM".

-- PMM