If we ever allow an interrupt to be handled by mulitple CPUs, this printf will have to go because spurious interrupts will become a normal thing.

IMO, it's two things. One thing is that we shuffle interrupts among cores, but each interrupt can fire only on one core. Thus, the situation will be same as it's now, just interrupt load could be balanced among cores. Another thing is, and certainly wanted one, that we allow an interrupt to be fired on whatever core it wants - the one free for interrupt dispatch. In that case, it depends on a controller if it's able to ensure that the very same interrupt does not fire on more than one core. If not, it's question if we disable such a feature or implement some locking to prevent such unwanted thing - an interrupt being served on more cores at same time.

Note that this is the reason for ARM_ISRCF_BOUND flag - a controller should know which interrupts must be bound to some core, and which interrupts are free to shuffle them among cores or enable them on all cores depending on its will and capability.

With GIC, the IRQ line into the cores will be signaled for all cores eligible to receive the interrupt. One of those cores will receive the interrupt number when reading the IAR, and the others will get 0x3ff. So GIC g'tees only one core processes an interrupt, we just have to stop whining about when it signals to other cores that they lost the race.

I really don't like this (void*) cast because of an intrng pic filter taking different args than a regular filter function. What if we say pic filter functions always take a pointer to a struct like:

struct arm_picfilter_data {
	void * pic_arg;
	void * trap_frame;
};

Where pic_arg is the arg value passed to bus_setup_intr() and trap_frame is what needs to be passed back to arm_irq_dispatch().

It's associated with INTR_SOLO, so at least it should be more like this:

struct intr_solofilter_data {
           void * solo_arg;
           struct trapframe * solo_tf; 
};

But to be honest, my vote is for (void*) cast if I could choose from these two possibilities.

In fact, I would like to see this INTR_SOLO stuff pushed to MI interrupt framework, i.e. intergrated to intr_event struct . ;)