Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t

[Sinha, Ani]

Thanks guys for the explanations. I'd try and add some comments to the code 
explaining the apis once I have a better understanding of the code. Right now I 
am still digesting the undocumented apis.

ani

On Sep 3, 2011, at 6:14 AM, Peter Maydell wrote:

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


============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================