From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iy9tA-00029T-P9 for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:42:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iy9t8-00028j-Sq for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:42:56 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iy9t8-00028b-GH for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:42:54 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Iy9t7-0007Sr-MG for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:42:54 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to printf target_phys_addr_t Date: Fri, 30 Nov 2007 17:42:48 +0000 References: <20071111154922.GE25322@tapir> <200711301650.55751.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711301742.49630.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl > 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