From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iy94y-00037V-5G for qemu-devel@nongnu.org; Fri, 30 Nov 2007 11:51:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iy94u-00033n-LE for qemu-devel@nongnu.org; Fri, 30 Nov 2007 11:51:03 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iy94u-00033T-3g for qemu-devel@nongnu.org; Fri, 30 Nov 2007 11:51:00 -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 1Iy94t-00044b-Q8 for qemu-devel@nongnu.org; Fri, 30 Nov 2007 11:51:00 -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 16:50:55 +0000 References: <20071111154922.GE25322@tapir> <20071130152126.GC28369@tapir> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711301650.55751.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 > > 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. 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. 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. 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. If you do for some reason have a host address you should use real host pointers. Usermode emulation complicates things a bit, but this isn't relevant for any of the code in hw/. Paul