From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LblC6-0008QL-0E for qemu-devel@nongnu.org; Mon, 23 Feb 2009 19:30:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LblC3-0008Q6-WD for qemu-devel@nongnu.org; Mon, 23 Feb 2009 19:30:40 -0500 Received: from [199.232.76.173] (port=57080 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LblC3-0008Q3-N0 for qemu-devel@nongnu.org; Mon, 23 Feb 2009 19:30:39 -0500 Received: from mx20.gnu.org ([199.232.41.8]:39316) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LblC3-0006og-FB for qemu-devel@nongnu.org; Mon, 23 Feb 2009 19:30:39 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LblC1-0002Ow-Ea for qemu-devel@nongnu.org; Mon, 23 Feb 2009 19:30:38 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses. Date: Tue, 24 Feb 2009 00:30:29 +0000 References: <200902231704.28500.paul@codesourcery.com> <49A33A81.1070800@earthlink.net> In-Reply-To: <49A33A81.1070800@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902240030.29683.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: Robert Reif Cc: qemu-devel@nongnu.org > Sparc devices are passed in their physical addresses. =C2=A0They are > currently hard wired > because there is no proper bus/slot layer and only on-broad devices are > implemented > anyway. =C2=A0However each system may have the same hardware located at > different locations > so this may not be typical QEMU behavior. Real hardware deals with real > addresses. Oh real hardware address decoding is typically implemented as chip selects = in=20 the host bridge, routing tables in the switch fabric, and/or having=20 individual devices do address decoding and claiming transactions on a share= d=20 bus. Modelling full per-device address decoding simply isn't feasible, we=20 have to use additional knowledge (e.g. PCI BARs or fixed address fanges) to= =20 perform that decoding at a higher level. > An IOMMU is irrelevant because the IOMMU emulation will take care of the > virtual to physical translation. Not really. An IOMMU exists as part of a bus bridge, and translates between= =20 different physical addresses on different busses. Virtual addresses (at lea= st=20 in any conventional sense) are an entirely separate layer that exists only= =20 within the CPU. Admittedly most IOMMU only act on device->CPU transactions,= =20 with CPU->device accesses using a static mapping. I'm pretty sure that the address reported by the CPU fault registers is the= =20 CPU bus address. With an IOMMU this is likely to be different to the addres= s=20 seen by the peripheral. Paul