In SMP, the system timer is used for timeslicing on auxiliary CPUs,
but the base system timekeeping via _nano_sys_clock_tick_announce() is
still done on CPU0 only (because the framework isn't prepared for
asynchronous notification yet). Skip processing on CPU1+.
Also, due to a hardware interaction* that is difficult to work around,
timer initialization on the auxiliary CPUs is done at the very end of
the CPU bringup, just before the swap into the scheduler. A
smp_timer_init() API has been added for this purpose.
* On ESP-32, enabling the timer seems to result in a near-synchronous
interrupt being delivered despite my best attempts to keep it
masked, then blowing things up because the CPU record isn't set up
to handle it yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that all the pieces are in place, enable SMP for real:
Initialize the CPU records, launch the CPUs at the end of kernel
initialization, have them wait for a flag to release them into the
scheduler, then enter into the runnable threads via _Swap().
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
In SMP mode, the idea of a single "IRQ lock" goes away. Long term,
all usage needs to migrate to spinlocks (which become simple IRQ locks
in the uniprocessor case). For the near term, we can ease the
migration (at the expense of performance) by providing a compatibility
implementation around a single global lock.
Note that one complication is that the older lock was recursive, while
spinlocks will deadlock if you try to lock them twice. So we
implement a simple "count" semantic to handle multiple locks.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Andy Ross