From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FRXjV-0006bH-T1 for qemu-devel@nongnu.org; Thu, 06 Apr 2006 12:53:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FRXjU-0006b5-4r for qemu-devel@nongnu.org; Thu, 06 Apr 2006 12:53:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FRXjT-0006b2-Ux for qemu-devel@nongnu.org; Thu, 06 Apr 2006 12:53:19 -0400 Received: from [212.8.0.13] (helo=rosi.naasa.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FRXnF-0002M8-Pl for qemu-devel@nongnu.org; Thu, 06 Apr 2006 12:57:14 -0400 From: Joerg Platte Subject: Re: [Qemu-devel] SPARC iommu mapping Date: Thu, 6 Apr 2006 18:53:12 +0200 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200604061853.13352.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 Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl: Hi! Today I did some more tests to determine, what's going wrong. At first, L= inux=20 flushes the page entries for the 14 buffers that are to be written to dis= k: IOMMU: page flush f001c000 IOMMU: page flush f001d000 IOMMU: page flush f001e000 IOMMU: page flush f001f000 IOMMU: page flush f0020000 IOMMU: page flush f0021000 IOMMU: page flush f0022000 IOMMU: page flush f0023000 IOMMU: page flush f0024000 Until here, the addresses are subsequent. Then the next address is much l= ower: IOMMU: page flush f000e000 IOMMU: page flush f000f000 IOMMU: page flush f0010000 IOMMU: page flush f0011000 IOMMU: page flush f0012000 Then, after sending the SCSI command, the DMA transfer starts: ESP: DMA Transfer Information len 00009000 ESP: DMA Direction: r, addr 0x0bdbb000 0000e000 Here, 0000e000 is the number of bytes to write accoring to the SCSI comma= nd.=20 In this case it equals the number of pages mentioned above (14). But Linu= x=20 stores 00009000 in the SCSI controllers transfer counter, which is less t= han=20 these 14 pages. Qemu's SCSI driver implementation now reads 14 pages and ignores the numb= er of=20 bytes written to the transfer register and writes 14 pages to disk: ESP: DMA address p 0bdbb000 v f001c000 ESP: DMA address p 0bdbc000 v f001d000 ESP: DMA address p 0bdbd000 v f001e000 ESP: DMA address p 0bdbe000 v f001f000 ESP: DMA address p 0bdbf000 v f0020000 ESP: DMA address p 0bdc0000 v f0021000 ESP: DMA address p 0bdc1000 v f0022000 ESP: DMA address p 0bdc2000 v f0023000 ESP: DMA address p 0bdc3000 v f0024000 No problem until here. ESP: DMA address p 00000000 v f0025000 Here, after 9 pages qemu tries to access page f0025000. But this page has= =20 never been written to the page table and therefore the mapped address is = 0.=20 The next page is f000e000. And this problem occures after 00009000 bytes=20 (which is the number of bytes written to the transfer register). Hence, t= he=20 kernel must adjust the DMA controller to point to the next address, becau= se=20 starting from here, there is a "gap" in the virtual address space. Curren= tly=20 I'm trying to understand the Linux kernel to figure out, whats the expext= ed=20 behaviour of this scsi controller. But it's not that easy, because I have= no=20 deep knowledge about the sparc hardware. What is expected, when the number of bytes from the transfer register hav= e=20 been read? Should the hardware raise an interrupt? And if yes, which flag= s=20 must be set? regards, J=F6rg