Don't actually implement it either yet, but at least don't abort.

We already get these from our API version of <sys/mount.h>

We don't use this header for user APIs and they conflict with the ones
from sys/mounts.h

console:init() calls wake() but the scheduler is not fully initialized at this
point, disable preemption as soon as main_cont starts and disable it after smp_launch()

avoids some spurious wakes to the callout thread

The algorithm we follow for memory discovery is quite simple: iterate over the
E820h map, and for every type 1 (== RAM) memory, we increment total size, and
map it linearly to our address space mappings.

That breaks on xen, however. I have no idea what is seabios doing for KVM, but
xen's hvmloader will put most of the ACPI tables at a reserved region around
physical address 0xfc000000. When we try to parse the ACPI tables, we will reach
an unmapped portion of the address space and fault (BTW, those faults are really
hard to debug, we're triple faulting directly, at least in my setup)

Luckily, the acpi driver code is prepared for such scenarios, and before using
any of that memory it will call map and unmap functions - we just don't implement
it.

This patch implements the necessary map function - and while we are at it, its
unmap counterpart. This is all far away from being performance critical, so I am
being as dump as possible and just servicing the request without tracking any
previous state.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

Make the function tracer work again.

Set it to have the largest possible vruntime, so it is only ever picked up
from the queue if there are no other threads on it.

This avoids a pointless context switch to the idle thread, where it wakes,
sees another thread, and switches out again.

usleep() was scrubbed out of POSIX in 2008, and not used in Java, but
it does exist in glibc and is damn easy to use compared to its newer
relative, nanosleep, so I want to use it in a test.

As Avi pointed out, shutdown_af_local() did read-modify-write to
f->f_flags without locking. Add the missing locks.

Remove things already done.

The functions that are used in function tracing must not themselves be
traced, lest we recurse endlessly.  Rather than marking them all with
no_instrument_function, keep a nesting counter and check if we're nested.
This way only the functions used for the test must not be traced.

Seeing a trace from an interrupt incurred while tracing can be confusing, so
disable them.

In the tracer, we don't want interrupt manipulation to cause recursion, so
provide uninstrumented versions of select functions.

This patch optionally enables, at compile-time, OSV to use the lock-free
mutex instead of the spin-lock-based mutex. To use the lock-free mutex,
change the line "#undef LOCKFREE_MUTEX" in include/osv/mutex.h to
"#define LOCKFREE_MUTEX".

LOCKFREE_MUTEX is currently disabled by default, awaiting a few more
tests, but at this point I'm happy to say that beyond one known
unrelated bug (see details below), it seems the lock-free mutex is
fairly stable, and survives all tests and benchmarks I threw at it.

The remaining known bug involves a thread destruction race between
complete() and join(): complete wake()s the joiner thread, which in
rare cases can really quickly delete the thread's stack, before wake()
returns, causing a crash on return from wake(). This bug is really
unrelated to the lock-free mutex, but for some unknown reason I can
only reproduce it with the lock-free mutex on the SPECjvm2008 "sunflow"
benchmark.

To make lockfree::mutex our default mutex, this patch does the following
when LOCKFREE_MUTEX is defined:

1. In core/mutex.cc, #ifndef away out the old mutex code, leaving the
   spinlock code in case someone wants to use it directly.

2. In include/osv/mutex.h, do different things in C++ and C (remember that
   lockfree::mutex is a C++ class, and cannot be used directly from C):

   * In C++, simply make mutex and mutex_t aliases for lockfree::mutex.

   * In C, make struct mutex and mutex_t an opaque 40-byte structure (in
     C++ compilation, we verify that this 40 is indeed the C++ class's
     length), and define the operations on it.

3. In libc/pthread.cc, if LOCKFREE_MUTEX, unfortunately the new mutex
   will not fit into pthread_mutex_t, and neither will condvar fit now
   into pthread_cond_t. So use a lazily allocated mutex or condvar, using
   the lazy_indirect<> template.

I have been commenting in and out lines in this script to choose the right
underlying hypervisor to run. So here is the automated version of it. I haven't
choosed the letters h or y because they usually denote help and yes,
respectively. Also not a kvm/no-kvm boolean because very soon we will like to
include xen.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

Now that we can actually see the debug message, print our name on it.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

We can use a very simple outb instruction to write data to the serial
port in case we don't have a console implementation yet. We don't need
to be fancy, and even limited functionality will already allow us to
print messages early, (specially debug).

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

We could benefit from the console being ready a bit earlier. The only
dependency that I see to it are the interrupts that need to be working.  So as
soon as we initialize the ioapic, we should be able to initialize the console.

This is not the end of story: we still need an even earlier console to debug the
driver initialization functions, and I was inclined to just leave console_init
where it is, for now.

But additionally, I felt that loader is really a more appropriate place for
that than vfs_init... So I propose we switch. In the mean time, it might help
debug things that happen between ioapic init and the old vfs_init (mem
initialization, smp bring up, etc)

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

Sorry, forgot one hunk in "git add -p" :(