From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FQrCA-00015a-Rb for qemu-devel@nongnu.org; Tue, 04 Apr 2006 15:28:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FQrC8-00013v-IZ for qemu-devel@nongnu.org; Tue, 04 Apr 2006 15:28:05 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FQrC8-00013r-AE for qemu-devel@nongnu.org; Tue, 04 Apr 2006 15:28:04 -0400 Received: from [212.8.0.13] (helo=rosi.naasa.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FQrFT-0002bk-JS for qemu-devel@nongnu.org; Tue, 04 Apr 2006 15:31:32 -0400 Received: from jako.ping.de (p50910853.dip0.t-ipconnect.de [80.145.8.83]) by rosi.naasa.net (Postfix) with ESMTP id B4F8822AEB5 for ; Tue, 4 Apr 2006 21:27:59 +0200 (CEST) From: Joerg Platte Date: Tue, 4 Apr 2006 21:27:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200604042127.55487.lists@naasa.net> Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] SPARC iommu mapping Reply-To: jplatte@naasa.net, 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 Hi! I still have problems when using a disk image for the SPARC system emulat= or.=20 Reading and writing now works better than in previous versions, but somet= imes=20 data written to image is simply corrupt. To find this problem I wrote a s= mall=20 program writing data to the beginning of a disk image. Afterwards I compa= red=20 the written data in the image with the expected values. Most of the data = was=20 correct, but sometimes a few pages mostly contains only zeros.=20 To find this problem, I enabled debugging in the esp.c file and printed t= he=20 mapped address (after iommu mapping). In some cases the mapped address is= =20 zero: Normal write: ESP: DMA Direction: r, addr 0x008fd000 0000000b ESP: DMA Direction: r, addr 0x0bea1000 0000e000 ESP: DMA address 0bea2000 ESP: DMA address 0bea4000 ESP: DMA address 0bea5000 ESP: DMA address 0bea6000 ESP: DMA address 0bea7000 ESP: DMA address 0bea8000 ESP: DMA address 0bea9000 ESP: DMA address 0beaa000 ESP: DMA address 0beab000 ESP: DMA address 0beac000 ESP: DMA address 0bead000 ESP: DMA address 0beaf000 ESP: DMA address 0beb0000 Faulty write: ESP: DMA Direction: r ESP: DMA Direction: r, addr 0x008fd000 0000000b ESP: DMA Direction: r, addr 0x0beb1000 0000e000 ESP: DMA address 0beb2000 ESP: DMA address 0beb3000 ESP: DMA address 0beb4000 ESP: DMA address 0beb5000 ESP: DMA address 0beb6000 ESP: DMA address 0beb7000 ESP: DMA address 0beb8000 ESP: DMA address 00000000 I used this code in handle_ti to produce this output: dmaptr =3D iommu_translate(s->espdmaregs[1] + i); if ((olddma&0xfffff000) !=3D (dmaptr&0xfffff000)) { DPRINTF("DMA address %08x\n", dmaptr); olddma=3Ddmaptr; } Unfortunately, I'm no hardware or SPARC expert and it took a whole day to= =20 track down this problem. So I'm not able to find the reason for this=20 behaviour. What may cause the wrong mapping? Is this some kind of page fa= ult,=20 which must be handled by the kernel? Or just a bug? regards, J=C3=B6rg