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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 22 April 2014 15:21, karim.allah.ahmed@xxxxxxxxx
<karim.allah.ahmed@xxxxxxxxx> wrote:
> 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 ).

Hi Karim,

My work is based on your repository, but it didn't work for me in its
original state. Mine is here:

https://github.com/talex5/xen

Some things I've added:

- Hypervisor calls were failing due to lack of the cache writeback attribute
- The regular console now works, not just the emergency console
- There's a fault handler which dumps the registers on a fault
- RAM settings are read from the FDT, getting the correct heap size
- The page allocator no longer corrupts memory
- Caching is enabled

> [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.



-- 
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