Re: [Xen-devel] Hypervisor crash setting up GIC (arm32)

["karim.allah.ahmed@xxxxxxxxx" <karim.allah.ahmed@xxxxxxxxx>]

Hi Thomas,

You can try to use the gic driver from here [0]. This branch is
basically a port of mini-os to ARM32, and it has a vgic driver ( and
vtimer ) working properly.

BTW, mini-os almost works ( check the TODO ) in this branch ( aside
from the fact that caching is disabled at the moment at mini-os and
hypervisor level .. because I had problem with hypercalls since I
didn't respect the EABI assumptions about caching ).


[0] https://github.com/KarimAllah/xen/tree/minios-arm-port

Regards.

On Tue, Apr 22, 2014 at 3:11 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> Hi guys,
>
> I've got a bit further and I'm now trying to get Mini-OS to handle
> interrupts. While testing, I got this hypervisor crash:
>
> (XEN) CPU1: Unexpected Trap: Data Abort
> (XEN) ----[ Xen-4.4.1-pre  arm32  debug=y  Not tainted ]----
> (XEN) CPU:    1
> (XEN) PC:     0022a444 _spin_lock+0x28/0x78
> (XEN) CPSR:   6000015a MODE:Hypervisor
> (XEN)      R0: 00000008 R1: 47fc6000 R2: 00000000 R3: 00000001
> (XEN)      R4: 00000000 R5: 47fc6000 R6: 00000c08 R7: 00000002
> (XEN)      R8: 00000002 R9: 40077f60 R10:00000302 R11:40077ea4 R12:2c001c08
> (XEN) HYP: SP: 40077e94 LR: 0022a430
> (XEN)
> (XEN)   VTCR_EL2: 80002558
> (XEN)  VTTBR_EL2: 000300004dce8000
> (XEN)
> (XEN)  SCTLR_EL2: 30cd187f
> (XEN)    HCR_EL2: 0000000000282837
> (XEN)  TTBR0_EL2: 0000000076011000
> (XEN)
> (XEN)    ESR_EL2: 94000006
> (XEN)  HPFAR_EL2: 00000000002c0010
> (XEN)      HDFAR: 00000000
> (XEN)      HIFAR: f1a720ce
> (XEN)
> (XEN) Xen stack trace from sp=40077e94:
> (XEN)    0022a430 0000001f 00000000 40077edc 0024ff4c 40077eb8 40077f20 
> 40077edc
> (XEN)    0024f3ac 0024ef50 40077f20 4007e000 93820047 00000001 00000001 
> 00000000
> (XEN)    93820047 40077eec 0024840c 00000001 40077f58 40077f54 0024ecb4 
> 002e6500
> (XEN)    4007e8dc 40077f0c 0022a570 00000001 4007e8dc 40077f3c 4007e8d4 
> 00000000
> (XEN)    4007e868 2c001000 00000000 93820047 2c001c08 2c001c08 00000000 
> 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> 40077f58
> (XEN)    00251130 00000001 00000000 00000000 2c001c08 00000000 00000000 
> 00000000
> (XEN)    00000000 00000000 00000000 00000000 8001ff8c deadbeef ffffffff 
> 00000000
> (XEN)    8000826c 20000113 c2c2c2c2 00000000 00000000 00000000 8001ff78 
> 80008630
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 
> 00000000
> (XEN)    00000000 00000000 c2c2c2c2 00000000 00000000 00000000 00000000 
> 00000000
> (XEN)    c2c2c2c2 c2c2c2c2 c2c2c2c2
> (XEN) Xen call trace:
> (XEN)    [<0022a444>] _spin_lock+0x28/0x78 (PC)
> (XEN)    [<0022a430>] _spin_lock+0x14/0x78 (LR)
> (XEN)    [<0024ff4c>] vgic_distr_mmio_write+0x530/0x854
> (XEN)    [<0024840c>] handle_mmio+0x8c/0x90
> (XEN)    [<0024ecb4>] do_trap_hypervisor+0x99c/0xa70
> (XEN)    [<00251130>] return_from_trap+0/0x4
>
> This is on the stable-4.4 branch again.
>
> This code in vgic.c looks suspicious:
>
>     case GICD_ICFGR + 2 ... GICD_ICFGRN: /* SPIs */
>         if ( dabt.size != 2 ) goto bad_width;
>         rank = vgic_irq_rank(v, 2, gicd_reg - GICD_ICFGR);
>         vgic_lock_rank(v, rank);
>         if ( rank == NULL) goto write_ignore;
>
> Maybe the NULL check should be moved before the lock?
>
>
> By the way, the original problem I'm having is that my IRQ handler
> keeps being called (continuously) with spurious interrupts (interrupt
> 1023). If anyone knows what might cause that, let me know!
>
> Thanks,
>
>
> --
> Dr Thomas Leonard        http://0install.net/
> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



-- 
Karim Allah Ahmed.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel