On Sat, Feb 26, 2011 at 6:52 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 26/02/11 16:36, Blue Swirl wrote:
A flush should be the removal of an entry, so I would guess that Solaris flushes the relevant entries and then adds them back into its IOMMU page table manually?
The flush would just affect an internal TLB, which is not implemented in QEMU, so the flush has no effect.
Right. So I added some extra code to QEMU again to get it to print the current translation for 0xfc000000 every time the IOMMU is accessed, and that looks like this:
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 110419968 ### Writing to iommu addr: 1, value 6bc000 0 --- Current translation for 0xfc000000 is 7fba06 ### Setting IOMMU base addr: 6bc000 ### Writing to iommu addr: 0, value 9 0 --- Current translation for 0xfc000000 is 0 ### Writing to iommu addr: 5, value 0 0 --- Current translation for 0xfc000000 is 0 ### IOMMU TLB flush 0 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 ### Writing to iommu addr: 6, value fc000000 0 --- Current translation for 0xfc000000 is 0 ### IOMMU page flush fc000000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 ### Writing to iommu addr: 6, value fc001000 0 --- Current translation for 0xfc000000 is 0 ### IOMMU page flush fc001000 qemu: fatal: Trap 0x29 while interrupts disabled, Error state
So the existing translation put in place by OpenBIOS is fine until the the IOMMU page table is switched, at which point we die because it doesn't get replaced.
The fact that it is the 0xc2 (DMA enabled) command which is issued rather than the 0x42 non-DMA version is making this seem more of a QEMU bug as opposed to an OpenBIOS bug. Surely a kernel must set up its DMA buffers first before attempting a DMA command?
Artyom: can you definitely boot Solaris 8 under OBP? And in fact, can you boot any of your other test images using OpenBIOS SVN trunk?
Blue: what debugging do I need to add to prove that this is the DMA bug you mentioned before?
Tracepoint logs with all points from both sparc32_dma.c and sun4m_iommu.c enabled?