[OpenBIOS] Solaris 8: ESP device enumeration issue

[Mark Cave-Ayland]

On 20/02/11 20:28, Mark Cave-Ayland wrote:

> Searching on the internet seems to suggest that IRQ 15 is used for
> distributing interrupts on multi-processor systems - so perhaps it is
> related to OpenBIOS' SMP setup? With a conditional breakpoint, I can see
> that they only start appearing upon activation of the first DMA transfer
> initiated by the Solaris kernel.

Ah so I think I have found the answer here: 
http://www.mail-archive.com/qemu-devel@nongnu.org/msg39793.html. So 
basically it seems this IRQ is being raised by the IOMMU because an 
attempt is made to access an unmapped I/O address.

Using a debug build of qemu, I placed a breakpoint on iommu_bad_addr in 
order to get a backtrace, and sure enough just after the Select with ATN 
I get a break here:

Breakpoint 1, iommu_bad_addr (s=0x1726020, addr=4227858432, is_write=0) 
at /home/build/src/qemu/git/qemu/hw/sun4m_iommu.c:279
279     {
(gdb) p/x 4227858432
$1 = 0xfc000000
(gdb) bt
#0  iommu_bad_addr (s=0x1726020, addr=4227858432, is_write=0) at 
/home/build/src/qemu/git/qemu/hw/sun4m_iommu.c:279
#1  0x0000000000549919 in sparc_iommu_memory_rw (opaque=0x1726020, 
addr=4227858464, buf=0x7fffac0c4560 
"\374\377\377\377\377\377\377\377\032\324T", len=7, is_write=0)
     at /home/build/src/qemu/git/qemu/hw/sun4m_iommu.c:303
#2  0x000000000054ccb7 in sparc_iommu_memory_read (opaque=0x1726020, 
addr=4227858464, buf=0x7fffac0c4560 
"\374\377\377\377\377\377\377\377\032\324T", len=7)
     at /home/build/src/qemu/git/qemu/hw/sun4m.h:15
#3  0x000000000054d2a1 in espdma_memory_read (opaque=0x182ce70, 
buf=0x7fffac0c4560 "\374\377\377\377\377\377\377\377\032\324T", len=7) 
at /home/build/src/qemu/git/qemu/hw/sparc32_dma.c:154
#4  0x000000000053f57b in get_cmd (s=0x1a66020, buf=0x7fffac0c4560 
"\374\377\377\377\377\377\377\377\032\324T") at 
/home/build/src/qemu/git/qemu/hw/esp.c:199
#5  0x000000000053f92e in handle_satn (s=0x1a66020) at 
/home/build/src/qemu/git/qemu/hw/esp.c:276
#6  0x00000000005409ec in esp_mem_writeb (opaque=0x1a66020, addr=12, 
val=194) at /home/build/src/qemu/git/qemu/hw/esp.c:631
#7  0x00000000004f151a in subpage_writelen (mmio=0x1a6c190, addr=12, 
value=194, len=0) at /home/build/src/qemu/git/qemu/exec.c:3260
#8  0x00000000004f15c0 in subpage_writeb (opaque=0x1a6c190, addr=12, 
value=194) at /home/build/src/qemu/git/qemu/exec.c:3271
#9  0x0000000000522797 in io_writeb (physaddr=12, val=194 '\302', 
addr=4119879692, retaddr=0x4134d166) at ../softmmu_template.h:213
#10 0x000000000052287c in __stb_mmu (addr=4119879692, val=194 '\302', 
mmu_idx=1) at ../softmmu_template.h:245
#11 0x000000004134d167 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0x1e8dd2975dfbc400 in ?? ()
#14 0x0000000000000000 in ?? ()

So it looks like the IOMMU doesn't have an entry mapped at 0xfc000000 
which is causing it to raise IRQ15. Now I see that OpenBIOS doesn't map 
that range in drivers/iommu.c - is that something we should be doing?

The other interesting part is why address 0xfc000000, since OpenBIOS 
must surely have pre-mapped ESP somewhere above 0xff000000 to be able to 
bootstrap the kernel from disk using DMA?

I see a reference here: 
http://www.mail-archive.com/qemu-devel@nongnu.org/msg13315.html that 
explicitly mentions this:

"Ok, I'll try to make a mental exercise with this chain:
SCSI->ESP->ESPDMA->IOMMU->memory write. Scenario: SCSI read issued, 8k
size. I'll track the address+size vectors at each stage.

scsi-disk uses host memory addresses. ESP uses addresses ranging from
0 to end of request. ESPDMA forces the MS byte to be 0xfc."

At the moment I can't quite figure out how/why this is happening in QEMU 
- does anyone have any pointers?


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs