Messages in this thread | | | Date | Mon, 12 May 2014 18:29:51 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 1/5] irq_work: Architecture support for remote irq work raise |
| |
On Mon, May 12, 2014 at 01:11:50PM +1000, Benjamin Herrenschmidt wrote: > 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.
Yeah, well if we ever end up with native remote irq work, only local raise will need to be NMI-safe. If that ever helps...
| |