When a tracepoint is disabled, we want it to have no impact on running code.

This patch changes the fast path to be a single 5-byte nop instruction.  When
a tracepoint is enabled, the nop is patched to a jump instruction to the
out-of-line slow path.

When some code section happens to be called from both thread context and
interrupt context, and we need mutual exclusion (we don't want the interrupt
context to start while the critical section is in the middle of running in
thread context), we surround the critical code section with CLI and STI.

But we need the compiler to assure us that writes to memory done between
the calls to CLI and STI stay between them. For example, if we have

    thread context:                 interrupt handler:

      CLI;                          a--;
      a++;
      STI;

We don't want the a++ to be moved by the compiler before the CLI. We also
don't want the compiler to save a's value in a register and only actually
write it back to the memory location 'a' after the STI (when an interrupt
handler might be concurrently writing). We also don't want the compiler
to remember a's last value in a register and use it again after the next
CLI.

To ensure these things, we need the "memory clobber" option on both the CLI
and STI instructions. The "volatile" keyword is not enough - it guarantees
that the instruction isn't deleted or moved, but not that stuff that
should have been in memory isn't just in registers.

Note that Linux also has these memory clobbers on sti() and cli().
Linus Torvals explains in a post from 1996 why these were necessary:
http://lkml.indiana.edu/hypermail/linux/kernel/9605/0214.html

All that being said, we never noticed a bug caused by the missing
"memory" clobbers. But better safe than sorry....

Drops context switch time by ~80ns.

Faster way to write fsbase on newer processors.

This patch adds missing FPU-state saving when calling signal handlers.
The state is saved on the stack, to allow nesting of signal handling
(delivery of a second signal while a first signal's handler is running).

In Linux calling conventions, the FPU state is caller-saved, i.e., a
called function can use FPU at will because the caller is assumed to have
saved it if needed. However, signal handlers are called asynchronously,
possibly in the middle of some FPU computation without that computation
getting a chance to save its state. So we must save this state before calling
the signal handling function.

Without this fix, we had problems even if the signal handlers themselves
did not use the FPU. A typical scenario - which we encountered in the
"sunflow" benchmark - is that the signal handler does something which uses
a mutex (e.g., malloc()) and causes a reschedule. The reschedule, not a
preempt(), thinks it does not need to save the FPU state, and the thread
we switch to clobbers this state.

musl doesn't define __isnan, so we must mark as a C function.

We want the size as well, to be able to munmap() pthread stacks.  Pass the
entire stack_info so we have this information.

Since we're packing the entire file system into the boot image, it has
overflowed the 128MB limit that was set for it.

Adjust the boot loader during build time to account for the actual loaded size.

Fixes wierd corruption during startup.

Previously we had two different mutex types - "mutex_t" defined by
<osv/mutex.h> for use in C code, and "mutex" defined by <mutex.hh>
for use in C++ code. This is difference is unnecessary, and causes
a mess for functions that need to accept either type, so they work
for both C++ and C code (e.g., consider condvar_wait()).

So after this commit, we have just one include file, <osv/mutex.h>
which works both in C and C++ code. This results in the same type
and same functions being defined, plus some additional conveniences
when in C++, such as method variants of the functions (e.g.,
m.lock() in addition to mutex_lock(m)), and the "with_lock" function.

The mutex type is now called either "mutex_t" or "struct mutex" in
C code, or can also be called just "mutex" in C++ code (all three
names refer to an identical type - there's no longer a different
mutex_t and mutex type).

This commit also modifies all the includers of <mutex.hh> to use
<osv/mutex.h>, and fixes a few miscelleneous compilation issues
that were discovered in the process.

Needed to pass metadata to Xen.

Easier for most users.

0xffff800000000000 is used by Xen, so avoid it.

Eliminate duplication.

Sorry, also forgot to commit this earlier!
Add a new function to send API to all processors accept this one.

Previously, we had the option to create a pinned thread, but it always
runs on the same CPU as the current thread, which is kind of odd. Changed
the boolean attribute "pinned" to a cpu* attribute specifying the cpu to
pin to.

Example code to run a start a new thread pinned on cpu 1:
new sched::thread([&]{...}, sched::thread::attr(sched::cpus[1]));

I need this feature to test the cross-CPU TLB flushing feature - I need
to be able to run two threads on two different CPUs.

Edge-triggered interrupts only, at present.

This is only causing confusion; change all callers to add '\n' explicitly
and drop the optional argument.

Thread object creation used to leak one page for the FPU state (thanks
Avi for spotting this). Fix this (add a destructor which frees the page)
and add to the test-suite a test for checking that thread creation doesn't
leak memory - and while we're at it, also checked that alloc_page() and
malloc() at various sizes do not leak memory.

We forgot to free the TCB allocated buffer on thread destruction, causing
a leak of around 1000 bytes per thread creation. We still have another
leak (exactly one page per thread object creation) that I'm trying to find :(

No need to explicitly construct a temporary function object.

In the existing code, #PF was handled correctly (generating a SIGSEGV),
but on most other x86 hardware exceptions, we just abort()ed the kernel.

The #DE (divide error) exception should, like #PF, generate a signal
(the inappropriately-named SIGFPE), and this patch does this. Strangely,
the SPECjvm2008 benchmark depends on this behavior (I didn't check its
source code to figure out why).

To make it easier to generate other signals in the future, I abstracted
the existing function handle_segmentation_fault() into a more general
generate_signal() which is used in both #PF and #DE handling.

Breaks on older processors.

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.