Although the regular SMP code is fine with keeping IPI_CPU_BACKTRACE
out of this count, we don't as we depend on it to figure out the exact
number of IPI vectors in use. The last IPI number we must allocate is
NR_IPI + IPIPE_LAST_IPI + 1, to account for the empty CPU_BACKTRACE
slot.

This bug badly breaks ipipe_raise_irq() by causing a conflict in the
VIRQ namespace between the last IPI and the first allocated VIRQ
allocated by the generic code (detected with deferred out-of-band
printk() messages not showing up).

Something moved the value of this constant but didn't update the
hard-coded instances. Fix this and avoid future problems by using the
proper symbolic value.

That just requires harding asm/ipipe_base.h for assembly use.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The mayday trap asks the co-kernel to deal with a runaway context
which has been detected earlier. When doing so, the co-kernel might
re-enable hard interrupts, which we have to disable again before
unwinding the IRQ context which triggered the whole process (like a
watchdog event).

Use __ipipe_call_mayday() to fire the notification to the co-kernel
instead of the open coded version, so that we do restore the hard
interrupt state properly before leaving __ipipe_exit_irq().

__ipipe_migrate_head() should not BUG() unconditionally when failing
to schedule out a thread, but rather let the real-time core handle the
situation a bit more gracefully.

Only timers stolen away from the host kernel should be early acked by
the pipeline core. Otherwise, the regular IRQ handler associated to
the timer would duplicate the action. The IRQ line is left masked,
waiting for the IRQ flow handler to unmask it eventually.