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

[Paul Brook <paul@codesourcery.com>]

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

If you're thinking of the warnings in op_goto_tb0, these are actually due to 
tb->tb_next having the wrong type.

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

cpu_physical_memory_* are the device memory access functions.

Also, on second viewing what I said isn't entirely true. There are two 
different cases: 

Some devices "own" their framebuffer, and can legitimately access it directly. 
ram_addr_t is a side-effect of the way qemu does ram allocation. With a 
proper dynamic allocation scheme this would be an opaque handle and/or a host 
pointer.

Other devices use system ram (which technically may not even be ram) for the 
framebuffer, so should be using the normal bus/device memory access routines.

Paul