From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iy9U6-0006yK-HV for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:17:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iy9U3-0006vY-Vb for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:17:02 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iy9U3-0006vR-R5 for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:16:59 -0500 Received: from hs-out-0708.google.com ([64.233.178.246] helo=hs-out-2122.google.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iy9Tm-0001Nm-8z for qemu-devel@nongnu.org; Fri, 30 Nov 2007 12:16:59 -0500 Received: by hs-out-2122.google.com with SMTP id 23so21481hsn for ; Fri, 30 Nov 2007 09:16:34 -0800 (PST) Message-ID: Date: Fri, 30 Nov 2007 19:16:32 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] [RESEND] hw/sh7750.c: use TARGET_FMT_plx to printf target_phys_addr_t In-Reply-To: <200711301650.55751.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071111154922.GE25322@tapir> <20071130152126.GC28369@tapir> <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: Paul Brook Cc: qemu-devel@nongnu.org On 11/30/07, Paul Brook wrote: > > > 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. Well, there is the physical memory size defined as int and various other places using unsigned long and even int. We discussed earlier replacing this with something better. > 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. It's currently a bug, yes. On the other hand, hard coding the usable device address space would allow compiling the device code just once for all targets. Many devices only need a few lowest address bits and a chip select (which for Qemu is the CPURead/WriteMemoryFunc). Of course the address registration mechanism would need some changes to support different bus widths. > 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. 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. > 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.