Re: [PATCH 1/5] irq_work: Architecture support for remote irq work raise

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2014-05-12 at 10:08 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-05-12 at 01:33 +0200, Frederic Weisbecker wrote:
> > We are going to extend irq work to support remote queuing.
> > 
> > So lets add a cpu argument to arch_irq_work_raise(). The architectures
> > willing to support that must then provide the backend to raise irq work
> > IPIs remotely.
> > 
> > Initial support is provided for x86 and ARM since they are easily
> > extended. The other archs that overwrite arch_irq_work_raise() seem
> > to use local clock interrupts and therefore need deeper rewrite of their
> > irq work support to implement remote raising.
> 
> Well, looks like it's time to turn it into an IPI... It gets a bit more
> tricky because whether whacking the interrupt controller is safe to
> do from an NMI is safe or not might depend on that irq controller
> implementation...
> 
> It looks like XICS and MPIC should be safe though, so at least we
> should be able to cover ppc64, but I'll leave ppc32 alone.

Correction... that's actually a bit more tricky. We might need an MMIO
to trigger the IPI. That means potentially having to take a hash miss,
and we certainly can't do that at NMI time at the moment.

We *could* hard disable interrupts (which blocks our NMIs since they
arent't real NMIs, they are just a way to bypass our soft-disable state
for perf interrupts) for hash_page, but that still makes me somewhat
nervous.

Another option would be to add an ioremap flag of some description to
be able to install bolted hash entries. (It already does so if called
early enough during boot, so it might actually just work by accident but
that's an undebuggable horror show waiting to happen if we ever change
that).

So needs a bit more thinking on our side.

Cheers,
Ben.