1. 07 Mar, 2021 7 commits
    • Jan Kiszka's avatar
      ipipe: Introduce and use ipipe_root_nr_syscalls · db1c6fd1
      Jan Kiszka authored
      At least one arch, infamous x86, has a difference of NR_syscalls
      depending on compat vs. native ABI. Account for that by introducing a
      function that can deliver the currently valid syscall number if an arch
      implements such a service. In all other cases, this change is
      functionally no difference.
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
    • Jan Kiszka's avatar
      ipipe: Introduce ptrace resume notifier · 71520eee
      Jan Kiszka authored
      This I-pipe hook reports the desired resumption mode to the subscriber:
      resume all process tasks or just single-step a particular one? The use
      case is to enable synchronous stopping / resuming of all head tasks of
      a ptraced real-time process.
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
    • Jan Kiszka's avatar
      ipipe: Introduce infrastructure for userspace return notifier · aaab39a7
      Jan Kiszka authored
      A little bit inspired by the kernel's user return notifier, this
      introduces an I-pipe hook before the kernel jumps back to a userspace
      context from the root domain. The hook is design to allow a switch back
      to the head domain, thus will not run through signal/preemption checks
      when returning from the callback over head. It is guaranteed to fire on
      return from interrupts and exceptions but may also fire on certain
      syscall-return paths.
      The first use case for the hook is resumption of ptraced tasks over
      head if they were stopped in that domain.
      This provides just the generic infrastructure, the invocation of
      __ipipe_notify_user_intreturn as well as the definition of
      TIP_USERINTRET are architecture-specific.
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
    • Philippe Gerum's avatar
      KVM: ipipe: keep hypervisor state consistent across domain preemption · 7b099da6
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      In order for the hypervisor to operate properly in presence of a
      co-kernel, we need:
      - the virtualization core to know when the hypervisor stalls due
        to a preemption by the co-kernel.
      - to know when the VM enters and leaves guest mode.
    • Philippe Gerum's avatar
      ipipe: add kernel event notifiers · 48858891
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      Add the core API for enabling (regular) kernel event notifications to
      a co-kernel running over the head domain. For instance, such a
      co-kernel may need to know when a task is about to be resumed upon
      signal receipt, or when it gets an access fault trap.
      This commit adds the client-side API for enabling such notification
      for class of events, but does not provide the notification points per
      se, which comes later.
    • Philippe Gerum's avatar
      preempt: ipipe: : add preemption-safe hard_preempt_{enable, disable}() ops · 15c424da
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      Some inner code of the interrupt pipeline may have to traverse regular
      kernel code which manipulates the preemption count, expecting full
      serialization including with out-of-band contexts.
      The hard_preempt_*() variants are substituted to the original
      preempt_{enable, disable}() calls in these cases.
    • Philippe Gerum's avatar
      genirq: add generic I-pipe core · fd239330
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      This commit provides the arch-independent bits for implementing the
      interrupt pipeline core, a lightweight layer introducing a separate,
      high-priority execution stage for handling all IRQs in pseudo-NMI
      mode, which cannot be delayed by the regular kernel code. See
      Documentation/ipipe.rst for details about interrupt pipelining.
      Architectures which support interrupt pipelining should select
      HAVE_IPIPE_SUPPORT, along with implementing the required arch-specific
      code. In such a case, CONFIG_IPIPE becomes available to the user via
      the Kconfig interface for enabling the feature.