qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t


From: Blue Swirl
Subject: Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t
Date: Sat, 3 Sep 2011 11:26:33 +0000

On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani <address@hidden> 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.



reply via email to

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