[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] SPARC iommu mapping
From: |
Joerg Platte |
Subject: |
Re: [Qemu-devel] SPARC iommu mapping |
Date: |
Thu, 6 Apr 2006 18:53:12 +0200 |
User-agent: |
KMail/1.9.1 |
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