* Hypervisor crash setting up GIC (arm32)
@ 2014-04-22 14:11 Thomas Leonard
2014-04-22 14:21 ` karim.allah.ahmed
2014-04-22 17:26 ` Thomas Leonard
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Leonard @ 2014-04-22 14:11 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Hypervisor crash setting up GIC (arm32)
2014-04-22 14:11 Hypervisor crash setting up GIC (arm32) Thomas Leonard
@ 2014-04-22 14:21 ` karim.allah.ahmed
2014-04-22 14:29 ` Thomas Leonard
2014-04-22 17:26 ` Thomas Leonard
1 sibling, 1 reply; 6+ messages in thread
From: karim.allah.ahmed @ 2014-04-22 14:21 UTC (permalink / raw)
To: Thomas Leonard; +Cc: xen-devel
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@gmail.com> 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@lists.xen.org
> http://lists.xen.org/xen-devel
--
Karim Allah Ahmed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hypervisor crash setting up GIC (arm32)
2014-04-22 14:21 ` karim.allah.ahmed
@ 2014-04-22 14:29 ` Thomas Leonard
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Leonard @ 2014-04-22 14:29 UTC (permalink / raw)
To: karim.allah.ahmed@gmail.com; +Cc: xen-devel
On 22 April 2014 15:21, karim.allah.ahmed@gmail.com
<karim.allah.ahmed@gmail.com> 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@gmail.com> 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@lists.xen.org
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hypervisor crash setting up GIC (arm32)
2014-04-22 14:11 Hypervisor crash setting up GIC (arm32) Thomas Leonard
2014-04-22 14:21 ` karim.allah.ahmed
@ 2014-04-22 17:26 ` Thomas Leonard
2014-04-23 15:35 ` Ian Campbell
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Leonard @ 2014-04-22 17:26 UTC (permalink / raw)
To: xen-devel
On 22 April 2014 15:11, Thomas Leonard <talex5@gmail.com> wrote:
> Hi guys,
>
> I've got a bit further and I'm now trying to get Mini-OS to handle
> interrupts. [...] my IRQ handler keeps being called (continuously)
> with spurious interrupts (interrupt 1023). If anyone knows what might cause that, let me know!
For reference, the problem here was this code:
gic_disable_interrupts(&gic);
gic_cpu_set_priority(&gic, 0xff);
gic_enable_interrupt(&gic, EVENTS_IRQ /* interrupt number */, 0x1
/*cpu_set*/, 1 /*level_sensitive*/, 0 /* ppi */);
gic_enable_interrupt(&gic, VIRTUALTIMER_IRQ /* interrupt number
*/, 0x1 /*cpu_set*/, 1 /*level_sensitive*/, 1 /* ppi */);
gic_enable_interrupts(&gic);
As soon as EVENTS_IRQ was enabled in gic_enable_interrupt, the IRQ
handler got called continuously with spurious interrupts and no
progress could be made.
The solution is to call gic_enable_interrupts *before* enabling the
individual interrupts.
The patch is on my Mini-OS branch here:
https://github.com/talex5/xen/tree/minios-arm-port
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Hypervisor crash setting up GIC (arm32)
2014-04-22 17:26 ` Thomas Leonard
@ 2014-04-23 15:35 ` Ian Campbell
2014-04-23 17:26 ` Jonathan Daugherty
0 siblings, 1 reply; 6+ messages in thread
From: Ian Campbell @ 2014-04-23 15:35 UTC (permalink / raw)
To: Thomas Leonard, Stefano Stabellini; +Cc: xen-devel
On Tue, 2014-04-22 at 18:26 +0100, Thomas Leonard wrote:
> On 22 April 2014 15:11, Thomas Leonard <talex5@gmail.com> wrote:
> > Hi guys,
> >
> > I've got a bit further and I'm now trying to get Mini-OS to handle
> > interrupts. [...] my IRQ handler keeps being called (continuously)
> > with spurious interrupts (interrupt 1023). If anyone knows what might cause that, let me know!
>
> For reference, the problem here was this code:
>
> gic_disable_interrupts(&gic);
> gic_cpu_set_priority(&gic, 0xff);
> gic_enable_interrupt(&gic, EVENTS_IRQ /* interrupt number */, 0x1
> /*cpu_set*/, 1 /*level_sensitive*/, 0 /* ppi */);
> gic_enable_interrupt(&gic, VIRTUALTIMER_IRQ /* interrupt number
> */, 0x1 /*cpu_set*/, 1 /*level_sensitive*/, 1 /* ppi */);
> gic_enable_interrupts(&gic);
>
> As soon as EVENTS_IRQ was enabled in gic_enable_interrupt, the IRQ
> handler got called continuously with spurious interrupts and no
> progress could be made.
Stefano, weren't the Galois guys seeing something similar? You fixed it
somewhere in a pending series IIRC?
>
> The solution is to call gic_enable_interrupts *before* enabling the
> individual interrupts.
>
> The patch is on my Mini-OS branch here:
>
> https://github.com/talex5/xen/tree/minios-arm-port
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hypervisor crash setting up GIC (arm32)
2014-04-23 15:35 ` Ian Campbell
@ 2014-04-23 17:26 ` Jonathan Daugherty
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Daugherty @ 2014-04-23 17:26 UTC (permalink / raw)
To: Ian Campbell; +Cc: Thomas Leonard, Stefano Stabellini, xen-devel
> Stefano, weren't the Galois guys seeing something similar? You fixed
> it somewhere in a pending series IIRC?
(Hi from Galois.)
Yes, we were seeing this problem in a big way; I can testify that
Stefano's branch, which contains numerous patches to improve/expand ARM
interrupt handling, has helped us considerably:
Repo: git://xenbits.xen.org/people/sstabellini/xen-unstable.git
Branch: no_maintenance_interrupts-v6
--
Jonathan Daugherty
Software Engineer
Galois, Inc.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-23 17:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-22 14:11 Hypervisor crash setting up GIC (arm32) Thomas Leonard
2014-04-22 14:21 ` karim.allah.ahmed
2014-04-22 14:29 ` Thomas Leonard
2014-04-22 17:26 ` Thomas Leonard
2014-04-23 15:35 ` Ian Campbell
2014-04-23 17:26 ` Jonathan Daugherty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).