1. 12 Dec, 2019 3 commits
    • Philippe Gerum's avatar
      ipipe: timer: allocate cpumask dynamically · 23d41712
      Philippe Gerum authored
      When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
      might overflow the stack with cpumask_t variables in
      ipipe_select_timer(). Allocate the cpumask we need there dynamically
      instead.
      23d41712
    • Philippe Gerum's avatar
      ipipe: switch potentially large cpumask to static storage · eebfa271
      Philippe Gerum authored
      When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
      might overflow the stack with cpumask_t variables in
      ipipe_critical_enter().
      
      Instead of allocating cpumask_var_t dynamically for these, rely on the
      fact that we cannot reenter the code accessing them by design, so
      those variables may be moved to local static storage.
      eebfa271
    • Philippe Gerum's avatar
      ipipe: add 4th mapping level to interrupt log · e93ec1cc
      Philippe Gerum authored
      Some configurations may define more than 256K distinct interrupts
      (e.g. CONFIG_MAXSMP/x86), which is the limit for the current 3-level
      mapping used for logging IRQs. Add a 4th mapping level to support
      configurations up to 16M interrupts.
      e93ec1cc
  2. 12 Oct, 2019 3 commits
    • Philippe Gerum's avatar
      arm64: ipipe: bump release code · 282d55f6
      Philippe Gerum authored
      282d55f6
    • Philippe Gerum's avatar
      arm64: ipipe: track IRQ state consistently upon BRK event · 5959f5c2
      Philippe Gerum authored
      Two related issues to address:
      
      1. Only after do_debug_exception() has told the irqsoff tracer about
      the IRQ state on entry to the handler should we invoke
      __ipipe_report_trap(), since the latter may have to switch the caller
      to the root domain, unstalling it in the same move, which will
      certainly affect the interrupt state.
      
      2. the debug monitor handler should be called once the hardware and
      virtual IRQ states are reconciled. To this end, enclose such call
      inside the fault_entry/fault_exit section.
      5959f5c2
    • Philippe Gerum's avatar
      arm64: ipipe: fix IRQ state mangling in fault entry · 0e5059bb
      Philippe Gerum authored
      This is a pretty bad issue affecting the logic involved in reconciling
      the virtual interrupt state with the hardware interrupt flags received
      on entry to any CPU exception.
      
      The net effect was a potentially corrupted virtual interrupt state on
      exit from the fault handlers.
      0e5059bb
  3. 11 Oct, 2019 2 commits
  4. 08 Oct, 2019 1 commit
  5. 01 Sep, 2019 13 commits
  6. 13 Jul, 2019 6 commits
  7. 24 Jun, 2019 12 commits