|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 0/2] xen/arm: maintenance_interrupt SMP fix
According to DT it is a level irq (DT_IRQ_TYPE_LEVEL_HIGH)
On Thu, Jan 30, 2014 at 3:24 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> Is it a level or an edge irq?
>
> On Wed, 29 Jan 2014, Julien Grall wrote:
>> Hi,
>>
>> It's weird, physical IRQ should not be injected twice ...
>> Were you able to print the IRQ number?
>>
>> In any case, you are using the old version of the interrupt patch series.
>> Your new error may come of race condition in this code.
>>
>> Can you try to use a newest version?
>>
>> On 29 Jan 2014 18:40, "Oleksandr Tyshchenko"
>> <oleksandr.tyshchenko@xxxxxxxxxxxxxxx> wrote:
>> > Right, that's why changing it to cpumask_of(0) shouldn't make any
>> > difference for xen-unstable (it should make things clearer, if
>> nothing
>> > else) but it should fix things for Oleksandr.
>>
>> Unfortunately, it is not enough for stable work.
>>
>> I was tried to use cpumask_of(smp_processor_id()) instead of
>> cpumask_of(0) in
>> gic_route_irq_to_guest(). And as result, I don't see our situation
>> which cause to deadlock in on_selected_cpus function (expected).
>> But, hypervisor sometimes hangs somewhere else (I have not identified
>> yet where this is happening) or I sometimes see traps, like that:
>> ("WARN_ON(p->desc != NULL)" in maintenance_interrupt() leads to them)
>>
>> (XEN) CPU1: Unexpected Trap: Undefined Instruction
>> (XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]----
>> (XEN) CPU: 1
>> (XEN) PC: 00242c1c __warn+0x20/0x28
>> (XEN) CPSR: 200001da MODE:Hypervisor
>> (XEN) R0: 0026770c R1: 00000001 R2: 3fd2fd00 R3: 00000fff
>> (XEN) R4: 00406100 R5: 40020ee0 R6: 00000000 R7: 4bfdf000
>> (XEN) R8: 00000001 R9: 4bfd7ed0 R10:00000001 R11:4bfd7ebc
>> R12:00000002
>> (XEN) HYP: SP: 4bfd7eb4 LR: 00242c1c
>> (XEN)
>> (XEN) VTCR_EL2: 80002558
>> (XEN) VTTBR_EL2: 00020000dec6a000
>> (XEN)
>> (XEN) SCTLR_EL2: 30cd187f
>> (XEN) HCR_EL2: 00000000000028b5
>> (XEN) TTBR0_EL2: 00000000d2014000
>> (XEN)
>> (XEN) ESR_EL2: 00000000
>> (XEN) HPFAR_EL2: 0000000000482110
>> (XEN) HDFAR: fa211190
>> (XEN) HIFAR: 00000000
>> (XEN)
>> (XEN) Xen stack trace from sp=4bfd7eb4:
>> (XEN) 0026431c 4bfd7efc 00247a54 00000024 002e6608 002e6608
>> 00000097 00000001
>> (XEN) 00000000 4bfd7f54 40017000 40005f60 40017014 4bfd7f58
>> 00000019 00000000
>> (XEN) 40005f60 4bfd7f24 00248e60 00000009 00000019 00404000
>> 4bfd7f58 00000000
>> (XEN) 00405000 000045f0 002e7694 4bfd7f4c 00248978 c0079a90
>> 00000097 00000097
>> (XEN) 00000000 fa212000 ea80c900 00000001 c05b8a60 4bfd7f54
>> 0024f4b8 4bfd7f58
>> (XEN) 00251830 ea80c950 00000000 00000001 c0079a90 00000097
>> 00000097 00000000
>> (XEN) fa212000 ea80c900 00000001 c05b8a60 00000000 e9879e3c
>> ffffffff b6efbca3
>> (XEN) c03b29fc 60000193 9fffffe7 b6c0bbf0 c0607500 c03b3140
>> e9879eb8 c007680c
>> (XEN) c060750c c03b32c0 c0607518 c03b3360 00000000 00000000
>> 00000000 00000000
>> (XEN) 00000000 00000000 3ff6bebf a0000113 800b0193 800b0093
>> 40000193 00000000
>> (XEN) ffeffbfe fedeefff fffd5ffe
>> (XEN) Xen call trace:
>> (XEN) [<00242c1c>] __warn+0x20/0x28 (PC)
>> (XEN) [<00242c1c>] __warn+0x20/0x28 (LR)
>> (XEN) [<00247a54>] maintenance_interrupt+0xfc/0x2f4
>> (XEN) [<00248e60>] do_IRQ+0x138/0x198
>> (XEN) [<00248978>] gic_interrupt+0x58/0xc0
>> (XEN) [<0024f4b8>] do_trap_irq+0x10/0x14
>> (XEN) [<00251830>] return_from_trap+0/0x4
>> (XEN)
>>
>> Also I am posting maintenance_interrupt() from my tree:
>>
>> static void maintenance_interrupt(int irq, void *dev_id, struct
>> cpu_user_regs *regs)
>> {
>> int i = 0, virq, pirq;
>> uint32_t lr;
>> struct vcpu *v = current;
>> uint64_t eisr = GICH[GICH_EISR0] | (((uint64_t) GICH[GICH_EISR1])
>> << 32);
>>
>> while ((i = find_next_bit((const long unsigned int *) &eisr,
>> 64, i)) < 64) {
>> struct pending_irq *p, *n;
>> int cpu, eoi;
>>
>> cpu = -1;
>> eoi = 0;
>>
>> spin_lock_irq(&gic.lock);
>> lr = GICH[GICH_LR + i];
>> virq = lr & GICH_LR_VIRTUAL_MASK;
>>
>> p = irq_to_pending(v, virq);
>> if ( p->desc != NULL ) {
>> p->desc->status &= ~IRQ_INPROGRESS;
>> /* Assume only one pcpu needs to EOI the irq */
>> cpu = p->desc->arch.eoi_cpu;
>> eoi = 1;
>> pirq = p->desc->irq;
>> }
>> if ( !atomic_dec_and_test(&p->inflight_cnt) )
>> {
>> /* Physical IRQ can't be reinject */
>> WARN_ON(p->desc != NULL);
>> gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority);
>> spin_unlock_irq(&gic.lock);
>> i++;
>> continue;
>> }
>>
>> GICH[GICH_LR + i] = 0;
>> clear_bit(i, &this_cpu(lr_mask));
>>
>> if ( !list_empty(&v->arch.vgic.lr_pending) ) {
>> n = list_entry(v->arch.vgic.lr_pending.next, typeof(*n),
>> lr_queue);
>> gic_set_lr(i, n->irq, GICH_LR_PENDING, n->priority);
>> list_del_init(&n->lr_queue);
>> set_bit(i, &this_cpu(lr_mask));
>> } else {
>> gic_inject_irq_stop();
>> }
>> spin_unlock_irq(&gic.lock);
>>
>> spin_lock_irq(&v->arch.vgic.lock);
>> list_del_init(&p->inflight);
>> spin_unlock_irq(&v->arch.vgic.lock);
>>
>> if ( eoi ) {
>> /* this is not racy because we can't receive another irq
>> of the
>> * same type until we EOI it. */
>> if ( cpu == smp_processor_id() )
>> gic_irq_eoi((void*)(uintptr_t)pirq);
>> else
>> on_selected_cpus(cpumask_of(cpu),
>> gic_irq_eoi, (void*)(uintptr_t)pirq,
>> 0);
>> }
>>
>> i++;
>> }
>> }
>>
>>
>> Oleksandr Tyshchenko | Embedded Developer
>> GlobalLogic
>>
>>
>>
--
Name | Title
GlobalLogic
P +x.xxx.xxx.xxxx M +x.xxx.xxx.xxxx S skype
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |