lkml.org 
[lkml]   [2014]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/5] irq_work: Architecture support for remote irq work raise
    From
    Date
    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.




    \
     
     \ /
      Last update: 2014-05-12 06:01    [W:3.445 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site