> 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
