Jan Kiszka wrote:

Thus what does 'acknowledege' exactly mean?


That the CPU confirms the interrupt controller that it picked up a
specific IRQ event. Depending on the IRQ type, this triggers various
activities in the interrupt controller. For some IRQ types, this can
also be a nop.

Note that the APIC is only one of the countless interrupt controllers in
this universe, implementing only a few of the possible IRQ types. The
universe is large, so a lot of very strange interrupt controllers
exist... ;)
(You may want to study vanilla Linux genirq code, how it handles all the
IRQ types - ipipe is a special case, not immediately revealing the hw
requirements behind it.)

ok, there is no single answer but it depends on the much differing hardware. It is good to keep that in mind in the future!
I shall try to look at the genirq code, will also be a good exercise to understand the linux kernel code in more detail.

but although the interrupt controller hardware can differ in general the following conclusion keeps :

When you forward the IRQ to Linux, you repy on Linux for
dealing with the periphery (acking the IRQ there) and the final
end-of-IRQ signal.

The shared IRQ handling algorithm is to consult all handlers in a loop until they all reported "not for me" in a row.

Thus for correct handling of shared IRQs, _all_ associate IRQ handlers, also
those in Linux, must have been executed before the EOI can be sent.

IRQ sharing between deterministic and non-deterministic code (here:
Xenomai and vanilla Linux) will never work, that's an inherent design
issue, nothing Xenomai or ipipe-specific.
(because the handling of the linux interrupt, is in fact executing code with none-realtime priority, which will delay the realtime system in a unpredicatable way!)

Thanks for all help,
Harco

Jan