Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t
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 blauwir...@gmail.com wrote: On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani ani.si...@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
Re: [Qemu-devel] target_phys_addr_t vs ram_addr_t
On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani ani.si...@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
On 3 September 2011 12:26, Blue Swirl blauwir...@gmail.com wrote: On Fri, Sep 2, 2011 at 6:08 AM, Sinha, Ani ani.si...@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
[Qemu-devel] target_phys_addr_t vs ram_addr_t
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
