Interrupt handling on QEMU < 1.2.5

[caltry]

On older version of QEMU, XINU seems to restart as soon as interrupts are enabled (i.e. as soon as you press the @ key). I thought that this was a QEMU bug for a while, but I haven't been able to find any discussions of anyone else having this problem.

You can test this out yourself with the qemu-system-arm on glados.

[caltry]

So, it looks like the root cause is that the jump table for the different IRQ handlers isn't being set up properly in the earlier versions of qemu.

on qemu-1.10:

   0x00010110 <+60>:    ldr     r0, [pc, #80]   ; 0x10168 <IRQ_Routine+148>
   0x00010114 <+64>:    ldr     r1, [r0, #48]   ; 0x30
=> 0x00010118 <+68>:    blx     r1
(gdb) print $r0
$4 = 269746176 (0x10140000)
(gdb) print $r1
$5 = 0

while on qemu-1.30:

   0x00010110 <+60>:    ldr     r0, [pc, #80]   ; 0x10168 <IRQ_Routine+148>
   0x00010114 <+64>:    ldr     r1, [r0, #48]   ; 0x30
=> 0x00010118 <+68>:    blx     r1
(gdb) print $r0
$4 = 269746176 (0x10140000)
(gdb) print $r1
$5 = 73960 (0x120E8 or clkhandler+0)

If I manually set $r1 in qemu-1.10, things function normally. So now i just need to figure out why there's nothing in the table at 0x10140000.

[caltry]

This is looking more and more like a QEMU bug. I've checked to make sure that the interrupt vector table is being filled properly -- and it is. We just seem to be getting 0 back as the address for the ISR.

14c126baf1c38607c5bd988878de85a06cefd8cf from the QEMU project seems to be a fix for this. It looks like it's an off-by-one error in the implementation of the pl190. I'll check to see if that is the cause of our errors by adding handlers for IRQs 3 and 5 (since IRQ 4 is our clock IRQ).

[tebrown]

Good work. I guess we could build out on qemu for the cs machines?

On Feb 3, 2013, at 2:00 AM, David Larsen notifications@github.com wrote:

This is looking more and more like a QEMU bug. I've checked to make sure that the interrupt vector table is being filled properly -- and it is. We just seem to be getting 0 back as the address for the ISR.

14c126b from the QEMU project seems to be a fix for this. It looks like it's an off-by-one error. I'll check to see if that is the cause of our errors by adding handlers for IRQs 3 and 5 (since IRQ 4 is our clock IRQ).

— Reply to this email directly or view it on GitHub.

[caltry]

Hmm... I can get a newer version of QEMU to work on glados without much trouble, but I might be able to get a decent work-around into XINU. I feel like having a work-around might be worthwhile since this bug was only recently fixed. I'll have to look into how much time a workaround would take.

@jsb2092 Can you get the quota for the course account bumped up an extra ~500MB to hold a newer QEMU?

In the meantime, I'll add a panic() if our ISR handler is 0x0, so we at least get an error message.