Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to printf target_phys_addr_t

["Blue Swirl" <blauwirbel@gmail.com>]

On 11/30/07, Paul Brook <paul@codesourcery.com> wrote:
> > >   target_phys_addr_t = physical address of the host
> > >   ram_addr_t = physical address of the guest
> >
> > No, target_phys_addr_t is the physical address of the emulated target
> > system. For host addresses ram_addr_t, unsigned long or even int is
> > used. Host addresses are of course virtual, Qemu is a user space
> > application until someone makes it run in bare metal without OS.
>
> Int should never be used to hold an address of any kind, and long probably
> shouldn't either. The only time you should use these is where you've got a
> known small offset, e.g after you've subtracted a base (physical) address to
> get an offset within an MMIO region.

Well, there is the physical memory size defined as int and various
other places using unsigned long and even int. We discussed earlier
replacing this with something better.

> Some of the arm devices use uint32_t for addresses, which is really a bug. We
> get away with it because these are only ever used by 32-bit targets.

It's currently a bug, yes. On the other hand, hard coding the usable
device address space would allow compiling the device code just once
for all targets. Many devices only need a few lowest address bits and
a chip select (which for Qemu is the CPURead/WriteMemoryFunc). Of
course the address registration mechanism would need some changes to
support different bus widths.

> target_ulong = target virtual address.
>
> target_phys_addr_t = target physical address. Because of the way TLB handling
> works these occasionally need to hold a host address. However these uses are
> local to the internals of the TLB code, and should never occur anywhere else.

I think T2 may need to store host addresses as well. To be frank, I
don't understand that part  but there is a compiler warning on a 64
bit host.

> In general all access to target memory should be via
> cpu_physcial_memory_{rw,read,write}
>
> For performance reasons we currently make an exception for framebuffer devices
> and allow them to access ram directly. ram_addr_t holds an offset from
> phys_ram_base.

Even better would be to make separate device memory access functions
and hide this exception.