Re: [Qemu-devel] SPARC iommu mapping

[Joerg Platte <lists@naasa.net>]

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, Linux 
flushes the page entries for the 14 buffers that are to be written to disk:
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 lower:

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 command. 
In this case it equals the number of pages mentioned above (14). But Linux 
stores 00009000 in the SCSI controllers transfer counter, which is less than 
these 14 pages.

Qemu's SCSI driver implementation now reads 14 pages and ignores the number of 
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 
never been written to the page table and therefore the mapped address is 0. 
The next page is f000e000. And this problem occures after 00009000 bytes 
(which is the number of bytes written to the transfer register). Hence, the 
kernel must adjust the DMA controller to point to the next address, because 
starting from here, there is a "gap" in the virtual address space. Currently 
I'm trying to understand the Linux kernel to figure out, whats the expexted 
behaviour of this scsi controller. But it's not that easy, because I have no 
deep knowledge about the sparc hardware.

What is expected, when the number of bytes from the transfer register have 
been read? Should the hardware raise an interrupt? And if yes, which flags 
must be set?

regards,
Jörg