> 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