[Qemu-devel] target_phys_addr_t vs ram_addr_t

[Qemu-devel] target_phys_addr_t vs ram_addr_t

[Sinha, Ani]

Hi Folks :

I am trying to write a virtio driver and towards this end I am looking at
the qemu code. I am a little confused about a few things. Unfortunately,
the few comments in the code does not make it clear for me. So I am
wondering if any kind person on this mailing list would be able to help.

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?

Secondly, in function cpu_physical_memory_map(), why is the length
parameter an address? If I look at the function virtqueue_map_sg(), the
sg.iov_len is defined as type size_t, which sounds like right. However,
this value is assigned to variable len which is of type
target_phys_addr_t. Is len an address or just a scalar value?

Lastly, in qemu_ram_ptr_length(), what is the length value? What does it
signify?

One more thing. It would really help guys like me if someone can add
comments regarding the various apis, what they do and what the parameters
mean in the code. I thought I'd suggest.

I am not in the mailing list. So please do a reply-all when responding.

Thanks in advance for help,
Ani


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

Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t

[Blue Swirl]

On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani <Ani.Sinha@tellabs.com> wrote:
> Hi Folks :
>
> I am trying to write a virtio driver and towards this end I am looking at
> the qemu code. I am a little confused about a few things. Unfortunately,
> the few comments in the code does not make it clear for me. So I am
> wondering if any kind person on this mailing list would be able to help.
>
> 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.

target_ulong is used for guest CPU registers and guest virtual
addresses. In the i386 guest with PAE case, this would remain 32 bits.
For a 64 bit guest, this is a 64 bit type. Normal devices may not use
this since it breaks the layering.

In your virtio case things are a bit more complicated since guest and
host share the same architecture. Paravirtualized devices may break
these rules with caution.

> Secondly, in function cpu_physical_memory_map(), why is the length
> parameter an address? If I look at the function virtqueue_map_sg(), the
> sg.iov_len is defined as type size_t, which sounds like right. However,
> this value is assigned to variable len which is of type
> target_phys_addr_t. Is len an address or just a scalar value?

size_t depends on host address size. Devices can map larger than 4G
physical areas even on a 32 bit host, so target_phys_addr_t must be
used.

> Lastly, in qemu_ram_ptr_length(), what is the length value? What does it
> signify?

The length of the RAM area. RAM can be non-contiguous and base address
may be nonzero.

> One more thing. It would really help guys like me if someone can add
> comments regarding the various apis, what they do and what the parameters
> mean in the code. I thought I'd suggest.

Patches are welcome :)

> I am not in the mailing list. So please do a reply-all when responding.

For many reasons it is a poor idea to develop code in-house without
constant communication to upstream developers, so please keep us
informed of your development (RFC patches etc.) if you intend to
submit it one day.

Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t

[Peter Maydell]

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

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


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