[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t

From: Peter Maydell
Subject: Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t
Date: Sat, 3 Sep 2011 14:14:11 +0100

On 3 September 2011 12:26, Blue Swirl <address@hidden> wrote:
> On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]