From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FRyaf-0005OS-Vr for qemu-devel@nongnu.org; Fri, 07 Apr 2006 17:34:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FRyac-0005Ky-Sm for qemu-devel@nongnu.org; Fri, 07 Apr 2006 17:34:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FRyac-0005Kv-Mm for qemu-devel@nongnu.org; Fri, 07 Apr 2006 17:33:58 -0400 Received: from [212.8.0.13] (helo=rosi.naasa.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FRyef-0003bB-D5 for qemu-devel@nongnu.org; Fri, 07 Apr 2006 17:38:09 -0400 From: Joerg Platte Subject: Re: [Qemu-devel] SPARC iommu mapping Date: Fri, 7 Apr 2006 23:33:47 +0200 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200604072333.48915.lists@naasa.net> Content-Transfer-Encoding: quoted-printable 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 Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl: Hi! > Thank you for the excellent analysis of the problem! Looks like Qemu > doesn't handle the case where DMA length and SCSI length are not equal. Exact. > So Linux splits the transfer into two parts to use two separate pieces = of > buffers. Funny, I thought this situation was exactly the one which > virtually addressed DMA would prevent from happening. I read somewhere, that Solaris and Linux unfortunately do not try to allo= cate=20 subsequent virtual addresses. > Yes, there will be an interrupt. I didn't find this situation in the > NCR53C9X.txt file documenting the ESP, though. Me too. I tried to understand what's going wrong, but it is not that easy= to=20 understand the Linux source, if you don't know much about the hardware an= d=20 the esp/iommu/dma/sbus architecture.=20 > There are two cases: > 1 - DMA length shorter than SCSI (your case) > 2 - SCSI length shorter (could happen in command replies etc.) > > Maybe this patch helps? Unfortunately not. I tried a similar approach, but it didn't work. Here i= s the=20 dump: First the mapping, similar to the one described in the last mail: IOMMU: page flush f0039000 IOMMU: page flush f003a000 IOMMU: page flush f003b000 IOMMU: page flush f003c000 IOMMU: page flush f003d000 IOMMU: page flush f003e000 IOMMU: page flush f003f000 IOMMU: page flush f0040000 IOMMU: page flush f0041000 IOMMU: page flush f0042000 IOMMU: page flush f0043000 IOMMU: page flush f0044000 IOMMU: page flush f0045000 IOMMU: page flush f000e000 Then the transfer, which stops after three pages, since the Transfer=20 information len is 12288: ESP: Transfer Information len 12288 ESP: DMA Direction: r, addr 0x0bdea000 0000e000 ESP: DMA address p 0bdea000 v f0039000 ESP: DMA address p 0bdeb000 v f003a000 ESP: DMA address p 0bdec000 v f003b000 ESP: Write callback (offset 224 len 112 size 57344 trans_size 12288) Now I would expect, that "somebody" (maybe the esp inerrupt handler) upda= tes=20 the dma registers to map the remaining pages. But this does not happen. L= inux=20 simply unmaps the old mapping: IOMMU: page flush f0039000 IOMMU: page flush f003a000 IOMMU: page flush f003b000 IOMMU: page flush f003c000 IOMMU: page flush f003d000 IOMMU: page flush f003e000 IOMMU: page flush f003f000 IOMMU: page flush f0040000 IOMMU: page flush f0041000 IOMMU: page flush f0042000 IOMMU: page flush f0043000 IOMMU: page flush f0044000 IOMMU: page flush f0045000 IOMMU: page flush f000e000 and configures a new one: IOMMU: page flush f000f000 IOMMU: page flush f0010000 IOMMU: page flush f0011000 IOMMU: page flush f0012000 IOMMU: page flush f0013000 IOMMU: page flush f0014000 IOMMU: page flush f0015000 IOMMU: page flush f0016000 IOMMU: page flush f0017000 IOMMU: page flush f0018000 IOMMU: page flush f0019000 IOMMU: page flush f001a000 IOMMU: page flush f001b000 IOMMU: page flush f001c000 Then, a few pages of the new mapping are written to disk: ESP: Transfer Information len 36864 ESP: DMA Direction: r, addr 0x0bdfa000 0000e000 ESP: DMA address p 0bdfa000 v f000f000 ESP: DMA address p 0bdfb000 v f0010000 ESP: DMA address p 0bdfc000 v f0011000 ESP: DMA address p 0bdfd000 v f0012000 ESP: DMA address p 0bdfe000 v f0013000 ESP: DMA address p 0bdff000 v f0014000 ESP: DMA address p 0be00000 v f0015000 ESP: DMA address p 0be01000 v f0016000 ESP: DMA address p 0be02000 v f0017000 ESP: Write callback (offset 336 len 112 size 57344 trans_size 36864) Then this ara is unmapped, and Linux continues with the next area. Hence, your patch avoids the zero mapping, but it does not provide the=20 required information which should result in a new dma addressing to write= the=20 remaining mapped data. Tomorrow, I'll try to enable more debbugging in th= e=20 Linux driver to try to find out what's going wrong. But with a real hardw= are=20 it's more difficult to get an idea of the internal functions :(=20 regards, J=F6rg