ipi(9) - NetBSD Manual Pages

Command:
Section:
Arch:
Collection:
>>>
IPI(9)                 NetBSD Kernel Developer's Manual                 IPI(9)


NAME

     ipi -- machine-independent interprocessor interrupts


SYNOPSIS

     #include <sys/ipi.h>

     typedef void (*ipi_func_t)(void *);

     u_int
     ipi_register(ipi_func_t func, void *arg);

     void
     ipi_unregister(u_int ipi_id);

     void
     ipi_trigger(u_int ipi_id, struct cpu_info *ci);

     void
     ipi_trigger_multi(u_int ipi_id, const kcpuset_t *target);

     void
     ipi_trigger_broadcast(u_int ipi_id, bool skip_self);

     void
     ipi_unicast(ipi_msg_t *msg, struct cpu_info *ci);

     void
     ipi_multicast(ipi_msg_t *msg, const kcpuset_t *target);

     void
     ipi_broadcast(ipi_msg_t *msg, bool skip_self);

     void
     ipi_wait(ipi_msg_t *msg);


DESCRIPTION

     The machine-independent ipi interface provides capability to send inter-
     processor interrupts (IPIs) amongst CPUs.  The interface has two mecha-
     nisms: asynchronous IPI to invoke functions with a constant argument and
     synchronous IPIs with the cross-call support.

     Other synchronization interfaces are built using the MI IPI interface.
     For a general purpose inter-processor cross-calls or remote interrupts,
     use the xcall(9) or softint(9) interfaces.

     The primary use cases of the MI IPIs include the following:
     -   provide a facility for the softint(9) subsystem to schedule software
         interrupts on remote CPUs
     -   provide a facility for the xcall(9) subsystem
     -   abstract IPI handling and facilitate machine-dependent code

   Asynchronous IPI interface
     This interface allows dynamic registration of IPI handlers with a con-
     stant argument and asynchronous triggering of interrupts.

     ipi_register(func, arg)
              Register an IPI handler func with an arbitrary argument arg.
              Returns a non-zero IPI identifier on success and zero on fail-
              ure.

     ipi_unregister(ipi_id)
              Unregister the IPI handler identified by the ipi_id.

     ipi_trigger(ipi_id, ci)
              Trigger an IPI identified by ipi_id on a remote CPU specified by
              ci.  This function must be called with kernel preemption dis-
              abled and the target CPU must be remote.

     ipi_trigger_multi(ipi_id, target)
              Trigger an IPI identified by ipi_id on all of the CPUs in the
              set specified by target.  This function must be called with ker-
              nel preemption disabled.  The sending CPU may be included in the
              CPU set; when this is the case, the IPI on the sending CPU is
              processes synchronously.

     ipi_trigger_broadcast(ipi_id, skip_self)
              Trigger an IPI identified by ipi_id on all of the attached CPUs.
              This function must be called with kernel preemption disabled.
              Optionally, the sending CPU may be skipped by passing true for
              skip_self.

   Synchronous IPI interface
     This interface provides capability to perform cross-calls, i.e. invoke an
     arbitrary function on a remote CPU.  The invocations are performed syn-
     chronously and the caller must wait for completion.  The cross-call is
     described by an IPI "message".  The caller has to fill in an ipi_msg_t
     structure which has the following public members:

             ipi_func_t      func;
             void            arg;

     The func member specifies a function to invoke and arg is the argument to
     be passed to the function.

     ipi_unicast(msg, ci)
              Send an IPI to a remote CPU specified by ci.

     ipi_multicast(msg, target)
              Send IPIs to a CPU set specified by target.

     ipi_broadcast(msg, skip_self)
              Send IPIs to all CPUs.  Optionally, the sending CPU may be
              skipped by passing true for skip_self.

     ipi_wait(msg)
              Wait until all IPIs complete.

     All described functions, except ipi_wait(), must be called with the ker-
     nel preemption disabled.  All synchronous IPI invocations must be com-
     pleted (wait for them with the ipi_wait() function) before the IPI mes-
     sage structure can be destroyed or new cross-call requests can be per-
     formed.


MEMORY ORDER

     All memory operations that happen before triggering an IPI, via
     ipi_trigger(), ipi_trigger_multi(), ipi_trigger_broadcast(),
     ipi_unicast(), ipi_multicast(), or ipi_broadcast(), also happen before
     any memory operations in the IPI handler function on the remote CPU.

     For synchronous IPIs, all memory operations that happen before the IPI
     handler function has returned on the remote CPU also happen before
     ipi_wait() returns on the waiting CPU.


NOTES

     Functions being called must be lightweight.  They run at IPL_HIGH and
     should generally not use any other synchronization interfaces such as
     mutex(9).  If spin-locks are used, they must be used carefully and have
     no contention.


CODE REFERENCES

     The ipi interface is implemented within the file sys/kern/subr_ipi.c.


SEE ALSO

     kcpuset(9), kpreempt(9), softint(9), spl(9), xcall(9)


HISTORY

     The ipi interface first appeared in NetBSD 7.0.


AUTHORS

     Mindaugas Rasiukevicius <rmind@NetBSD.org>

NetBSD 10.99                    March 31, 2019                    NetBSD 10.99