Because we are now pre-computing wall clock, we only need preemption disabled during system
time calculation.

The tracepoints in lfmutex.cc referred to the type "mutex" outside the
"lockfree" namespace. When LOCKFREE_MUTEX is disabled in osv/mutex.h,
"mutex" is not an alias of "lockfree::mutex" so this does not compile.

Move the tracepoints inside the namespace, so they can use "mutex"
and got the right one.

A bunch of improvements to tst-mutex. Add another mutual-exclusion
test case, some asserts, and a benchmark of the "handoff" corner
case.

This is a bit different from FreeBSD (which already differs from Solaris)
because our VFS generally already has an allocated vnode around.

Xen defines a protocol for defining whether or not PV drivers are available in
an HVM guest. Upon successful negotiation, the documentation states that:

"The relevant emulated devices then disappear from the relevant buses.  For
most guest operating systems, you want to do this before device enumeration
happens."

This patch basically follows this protocol and stores the result for future usage.

See more at: docs/misc/hvm-emulated-unplug.markdown

This reverts commit dae99589.

Xen's information can be in a variety of MSRs. We need to test for them all
and figure out in which of them lays the informations we want.

Once we determine that, xen initalization code is ready to be executed.
This needs to run as early as possible, because all xen drivers will
make use of it one way or another.

The hypercall code is heavily inspired (aka mostly copied) from Avi's
xen tentative patch, with the 5-argument hypercall removed (delayed until
we need it)

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

I am pretty sure kvmclock only sets the wall time when we write to the MSR,
so there is no point in keep calculating it every time we call system_time().

I am not changing it to a const function because we *may* have to call it
more than once in the future, if we ever suspend, or the likes. But for now,
using a pre-computed value is enough.

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

This is not a very serious issue, but goes like this: The very simple read
method we are attempting right now in the loader, will keep reading from the
disk until we reach a pre-determined max size. However, the disk is usually
smaller than this. If this is the case, XEN dmesg logs are filled with messages
indicated that we are trying to read from invalid LBAs, to the point of making
the log useless for me.

So although the annoyance is minor, the patch itself is minor too. If nobody
opposes, I can apply it.

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

The "events", not "revents", field of the poll structure needs to be set
before calling poll().

Add tst-epoll.cc for testing the epoll_*() functions.
This test finds a bug, which will be fixed in a separate patch.

Not wired up yet due to the problems of creating a zfs fs on the host.

This patch solves issue #11, where join() hangs were seen in tst-mutex, with
threads remaining in "terminating" state.

The problem was that complete() assumed that _cpu->terminating_thread was
nullptr, so it could overwrite it with the current thread. This is usually
true - when we switch to any thread, if terminating_thread!=0 it is
handled. The problem is that when we switch to a *new* thread (in
sched::init(), call switch_to_first()) this code does not run, and if
this thread quickly terminates, _cpu->terminating_thread gets overwritten
instead of being handled.

The simplest workaround, in this patch is simply to handle (i.e., call
unref()) the previous _cpu->terminating_thread before overwriting it.

The downside with this approach is that the termination of a thread
may be delayed by the run time of the first time-slice of a new thread.

But we anyway plan to eventually replace this termination mechanism
(see issue #10), so I think this solution is fine.

Starting the CLI and using the run command by specifying it as a run.py argument
didn't work due to a cast problem (run expected NativeArray).

previousely this didn't work:

$ sudo ./scripts/run.py -n -e "java.so -jar /java/cli.jar run tools/netserver-osv -D -4 -f -N" -c2 -m1G

This reverts commit ccaad30c.

VIRTIO_RING_F_EVENT_IDX and VIRTIO_RING_F_INDIRECT_DESC are
defined in virtio.hh

No need to assign the condvar initializer, this is C++ after all and objects
are initialized by default anyway.

When a callout is deleted, it is properly deleted from the set of
callouts, but if it was the next-in-line to run, it was also saved
in a local variable while waiting for its timer to expire, and could
be run despite being deleted.

The Shrew test HTTP server (see bug 7) exposed this bug - every once
in a while (usually very quickly) when a socket was deleted had a
crash when a callout referring to the deleted socket was run.

Thanks to Guy for finding and fixing this bug.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>