> To find this problem, I enabled debugging in the esp.c file and printed
the
> mapped address (after iommu mapping). In some cases the mapped address
is
> zero:
> ESP: DMA address 0beb8000
> ESP: DMA address 00000000
I didn't find a manual of the SBUS IOMMU. But if I understand the contents
of
newer implementations of an IOMMU, each entry in this MMU table has a valid
bit. And therefore, a 0 entry is invalid. But the current implementation of
qemu's IOMMU does not check for a valid bit. Where can I find more
information on this topic? And is a besser IOMMU currently in development?
I don't have any better documentation either, I just coded against what
Proll and Linux expect. But the theory of operation is simple. Much like how
the MMU translates CPU's virtual addresses to physical addresses for memory,
IOMMU translates device virtual memory accesses to physical addresses. The
VA to PA entries are found in a simple page table.
In the case of not finding a valid translation entry, IOMMU can't fault the
device like normal MMU can easily fault the CPU. I don't know what should
happen then, probably put the address to AFAR register and raise some
interrupt, while the device (for example Ethernet controller) waiting for
the data suffers in limbo. I think it would be strange for an OS to rely on
this, so I guess it's a bug somewhere else. My guess for the valid bit is
that it's used in a real IOMMU to select the entries that will be loaded to
its internal translation buffer.
The DMA controllers for both ESP and Lance are within the same page. This
means that in Qemu, DMA controller register accesses for either of them go
to just one of these. It just happens to work, but maybe this causes the
problem. You could try to confirm this by enabling also DEBUG_LANCE and see
if there is troublesome activity in the Lance direction near the bad
accesses.
Can you provide a test case so that I could try it as well?
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
