Used the wrong bit.

Due to the "red zone", stack operations may corrupt local variables.
Use ordinary moves and jumps instead.

Normal scheduling does not need to save or restore the fpu when switching
threads, since all fpu registers are caller-saved (so calling schedule()) may
clobber the fpu).  However this does not hold on preemption, so we need
to save and restore the fpu state explicitly.

Parse cpuid flag bits relevant to osv.

With the current memset(), every thread starts out with zero-initialized
tls variables.

Switch to memcpy(), so it gets the proper static initializer.

Fixes conf-preempt=0.

This only implements SIGSEGv delivery to the thread that triggered it
(i.e., it must be unblocked).

Found by eclipse.

Split the core scheduler into a function for calling from interrupts, and
a wrapper for calling it from normal paths.  Call the preemptible path from
interrupt handlers.

With preemption, we may switch threads in an interrupt.  This means we can
no longer use a per-cpu exception stack, since every thread in the system
can potentially be preempted.

Switch to a per-thread exception stack instead.  This adds overhead to
the context switch path, but it is negligible (a single memory write).

Currently it is uninitialized, which breaks things later on.

We did not correctly skip memory regions above the PCI hole during
the first phase of mapping memory below 1G.

Due to a cut-and-paste error, the area below 1GB was double freed if more
than 1GB was present, leading to freelist corruption.

boost::format allocates, and we're not quite ready to schedule at this
state; drop the debug message (unneeded anyhow).

We also make the deleter configurable so we can use munmap() or similar
to destroy the stack of payload threads.

Previously, we performed idle processing in the scheduler, in the context
of the thread that is being scheudled out.  This makes preemption more
complicated, since every thread can potentially be in the idle loop
simultaneously, having been preempted there some time in the past.  Obviously
we can't disable interrupts in the idle loop.

Move idle processing to its own thread to fix this problem.  This is currently
sub-optimal since we don't have priority classes yet (or even just priorities),
so the idle thread can be scheduled before workload threads.  If that happens
it will examine the runqueue and yield if there's anything there.

Otherwise, expect memory corruption.

See README for instructions.

We need it from several places; use a function to find it.

While easy to use, auto-starting threads generates problems when more
complicated initialization takes place.

Rather than making auto-start optional (as Guy suggested), remove it
completely, to keep the API simple.

Use thread::start() to start a thread.  Unstarted threads ignore wakeups
until started.

We don't want to be preempted during a context switch, since thread
state invariants will not be maintained.

We store it in a global rather than passing it on the stack since it's
only useful in a few contexts.  Our interrupts don't nest so it's pretty
simple.

Also add an arch independent name for it.

This avoids spurious interrupts from the PIC (even though it has been
disabled).

At present, a trivial algorithm is used: wake up once in a while, look for
a less-loaded cpu, and push a waiting thread from this cpu to the other cpu.

This is very simple wrt. locking, since the waiting thread is guaranteed not
to be running, and to be on the runqueue of the load balancer thread.

This allows copying thread::attr objects around without leaking stacks.

This makes it easy to configure a thread with various parameters.  The first
is the existing stack_info parameter.

The apic needs to be programmed on each cpu that is brought up.

We used cpu_arch::init_on_cpu() instead of the arch-indepdendent version.

Each cpu has a queue (actually an array of queues, one for each "waking" cpu)
of threads that are to be woken.  A thread can be queued locklessly, so a
runqueue lock is not needed.

As we don't IPI yet, the queues are polled at strategic points.

While generally useful, it helps now to avoid wakeups to threads that are
no longer there.