Re: [Qemu-devel] State of ARM FIQ in Qemu

[Greg Bellows]

Hi Tim,

Responses inline.

Regards,

Greg

On 4 November 2014 09:40, Tim Sander <address@hidden> wrote:

Hi Greg
> Ah... Yes, using A9 (GICv1) which means you don't have grouping without the
> security extensions.
Ok switching the GIC to version 2 works seems to work. In a way that Linux still
boots up and i get a FIQ.

I have some problems still:
It seems as if the exeption of the bugsplat below
is called from handle_fasteoi_irq (or is it just interrupted?). Which would mean
that the cpu is not jumping to the FIQ handler but the normal irq handler. This
might point to a problem in the qemu FIQ code. But i am not sure, so the error
might also be in the linux user mode.

I have loaded a firmware my driver module with "set_fiq_handler" but the area
where the fiq has landed (0xfff1240) is filled completly with zeros?

Best regards
Tim

Bad mode in data abort handler detected
Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP ARM
Modules linked in: firq(O) ipv6
CPU: 0 PID: 103 Comm: systemd-udevd Tainted: G           O 3.14.0 #1
task: bf2b9300 ti: bf362000 task.ti: bf362000
PC is at 0xffff1240
LR is at handle_fasteoi_irq+0x9c/0x13c
pc : [<ffff1240>]    lr : [<8005cda0>]    psr: 600f01d1
sp : bf363e70  ip : 07a7e79d  fp : 00000000
r10: 76f92008  r9 : 80590080  r8 : 76e8e4d0
r7 : f8200100  r6 : bf363fb0  r5 : bf008414  r4 : bf0083c0
r3 : 80230d04  r2 : 0000002f  r1 : 00000000  r0 : bf0083c0
Flags: nZCv  IRQs off  FIQs off  Mode FIQ_32  ISA ARM  Segment user

It looks like we are in FIQ mode and interrupts have been masked.

 

Control: 10c53c7d  Table: 60004059  DAC: 00000015
Process systemd-udevd (pid: 103, stack limit = 0xbf362240)
Stack: (0xbf363e70 to 0xbf364000)
3e60:                                     bf0083c0 00000000 0000002f 80230d04
3e80: bf0083c0 bf008414 bf363fb0 f8200100 76e8e4d0 80590080 76f92008 00000000
3ea0: 07a7e79d bf363e70 8005cda0 ffff1240 600f01d1 ffffffff 8005cd04 0000002f
3ec0: 0000002f 800598bc 8058cc70 8000ed00 f820010c 8059684c bf363ef8 80008528
3ee0: 80023730 80023744 200f0113 ffffffff bf363f2c 80012180 00000000 805baa00
3f00: 00000000 00000100 00000002 00000022 00000000 bf362000 76e8e4d0 80590080
3f20: 76f92008 00000000 0000000a bf363f40 80023730 80023744 200f0113 ffffffff
3f40: bf007a14 8059ac00 00000000 0000000a ffff8dd7 00400140 bf0079c0 8058cc70
3f60: 00000022 00000000 f8200100 76e8e4d0 76f9201c 76f92008 00000000 80023af0
3f80: 8058cc70 8000ed04 f820010c 8059684c bf363fb0 80008528 00000000 76dd3b44
3fa0: 600f0010 ffffffff 0000000c 8001233c 00000000 00000000 76f93428 76f93428
3fc0: 76f93438 00000000 76f93448 0000000c 76e8e4d0 76f9201c 76f92008 00000000
3fe0: 00000000 7ec115c0 76f60914 76dd3b44 600f0010 ffffffff 9fffd821 9fffdc21
[<8005cda0>] (handle_fasteoi_irq) from [<80230d04>] (gic_eoi_irq+0x0/0x4c)

It certainly looks like we are going down the standard IRQ patch as you suggested.  I'm not a Linux driver guy, but do you see any kind of activity (break points, printfs, ...) through your FIQ handler?

 

[<80230d04>] (gic_eoi_irq) from [<f8200100>] (0xf8200100)
Code: ee02af10 f57ff06f e59d8000 e59d9004 (e599b00c)
---[ end trace 3dc3571209a017e1 ]---
Kernel panic - not syncing: Fatal exception in interrupt

It is hard to determine entirely what is happening here based on this info.  I do have code of my own that routes KGDB interrupts as FIQs and with the workaround I see the FIQs handled as expected.  Some things we can try to get more info in hopes of pinpointing where to look:

1. At the top of hw/intc/arm_gic.c there is the following commented out line:
       //#define DEBUG_GIC
   Uncomment the line, rebuild and rerun.  This will give us some trace on what is going through the GIC code.
2. Run qemu with the "-d int" option which will print a message on each interrupt.  We should see an FIQ at some point if they are occurring. The only issue is that there will be numerous IRQs, so you'll have to parse through them to find an "exception 6 [FIQ].
3. If you set a breakpoint in your driver, is it possible to see that FIQs are on from the kernel debugger.  Clearly you have to try this from a path where interrupts are masked.  I see the following on my system mentioned above:
   ...
   Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
   ...