Added Cloudius copyright statement to our own code in include/.
Also added include/api/LICENSE saying that these are copied from Musl
and public domain (according to the Musl COPYRIGHT file).

This patch addes a "LICENSE" file, explaining our copyright status and
3-clause BSD license.

It also includes in documentation/LICENSE-* the licenses of the four projects
we copied code from - FreeBSD, Prex, Open Solaris and Musl. Our top-level
LICENSE file refers to these separate LICENSE files.

Add "CONTRIBUTING" file, with instructions based mostly on Linux's
"Developer's Certificate of Origin 1.1" (Documentation/SendingPatches).

Added Cloudius copyright statement to source files in fs/ which are our
own code (and not from Prex or FreeBSD). Also added our copyright statement
in addition to the original one when I thought we made non-trivial changes
to the original.

Add Cloudius copyright and license statement to drivers/*.

A couple of header files were based on Linux's BSD-licensed header files
(e.g., include/uapi/linux/virtio_net.h) so they included the BSD license,
but not any copyright statement, so we can just replace that by our own
statement of the BSD license.

Added Cloudius copyright statement to core/*.

poll.cc already had a BSD copyright statement, I believe this is a mistake
(I think Guy wrote this code from scratch), but not wanting to rush to a
conclusion I'm leaving both copyright statements and we should address this
issue later.

Added copyright statement to all Javascript commands for our old CLI, in
console/*. We should eventually remove this directory, but while it still
exists, let's add copyright statements.

Added our copyright statements to some of the files in the top bsd/
directory, and in bsd/porting.

I only added our copyright to files which were completely by us - I did
not attempt to hunt which bsd or solaris files we modified to add our
copyright to them, I don't think this is important (or, we can do this
later).

I also found one header file (uma_stub.h) that had large chunks copied from
freebsd, so I added both the freebsd copyright and ours.

Add Cloudius copyright to everything in arch/x64. This includes C++ code, assembly
code, and ld scripts.

Sorry, previous commit left loader.cc with only a copyright statement.
Our copyright is important, but not *that* important!
I'll be more careful next time...

Add copyright statement to the source files in the top-level directory (except the
trivial dummy-shlib.cc).

By the way, I don't think this code really belongs in the top-level directory.

* %lu => %u when reading flush. The barrier flag had the same bug, but I
ended up recreating it for flush.
* Move check of xb_flags to after we check sc->flags != NULL, as spotted by
Dima

Pass function arguments to the tracepoint and add a tracepoints for
poll() return value and errno.

I've made the mistake of presenting the counter value directly instead of
converting it to nanoseconds. We need to do that, by grabbing the period from
the device and using it.

Since hpet is already our slow fallback anyway, I am using simple
multiplication and not bothering with complex mult / shift stuff.

Not all Xen versions implement the barrier feature in their pv disks. Such is
the case in Amazon EC2. For those, we should interpret the flush request and
wait for the requests until they are all handled. Also, we can still try to use
one of either barriers or flush-disk operations before we resort to guest-side
software implementation. Our driver currently only tests for one of them, so
this patch also implements flush requests.

Luckily, the implementation of xb_dump (which we don't currently use) needs to
do that as well, and this is also quite well isolated in xb_quiesce(). All we need
to do is call xb_quiesce() if flushing is not available in our backend

The Xen hypervisor not always initialize its pages. The BSD drivers will
however assume they are zeroed, and so things may break if they are not
(misterious flag tests suddenly being true, for instance).

Initialize manually the data we have just received from malloc when we deal
with softc.

Even Lords make brown paper bag mistakes. This is a left over code from my
initial testing, where the buffer where set with pre existing values to make
sure they were going through.  I forgot to remove them. As a result reads were
fine, but writes would just wipe the previous data from the buffer.
Incidentally, the "write-then-read-the-data-back" test I was doing would also
obviously pass, so I haven't noticed this so far.

Fix is to just leave the buffer alone.

So far, our run.py script only runs qemu-based VMs, like KVM. For Xen, I was
resorting to manually run xl. This patch implements xen support in that script.

We do need a bit of extra information, like the bridge name. I am defaulting to
F19's, allowing the user to set it up. We can do better by trying to guess from
reading what is in the system, but this will do for now.

Another problem is the console, which Xen does not redirect to stdio. We have
to attach one, but detaching it does not kill the guest, as it happens with the
qemu-based VMs. Because of that, I am defaulting to include the "-c" option to
automatically attach a console, but for people who would like to have it on
background, an option to not include it.

As I have stated previously, what is true for qemu (that we always have
a user-provided network interface) is not true for Xen. It is quite possible
that we boot with no network interface at all. In that case, we will get stuck
asking for an IP that will never come.

This patch takes care to call for dhcp only if our interface is really up. Since
networking is such a core service, we'll print a message if we can't do that.

Some time ago I have moved the console initialization a bit earlier, so
messages could be seen earlier. This has been, however, creating spurious
problems (1 at each 10 - 15 boots) on Xen HVM. The reason is that the isa
serial reset code enables interrupts upon reset, and the isa irq interrupt
will call wake() in the pool thread, which at this point is not yet started.

Since these days we already have simple_write() dealing with the early stuff,
move it back to where it used to be.

P.S: Dima found a way to make this problem 100 % reproduceable, by queueing
data in the input line before the console starts. With this patch, the problem
is gone even if Dima's method is used.

msleep() measure times in units of 1/hz seconds. We had hz = 1,000,000,
which gives excellent resolution (microsecond) but a terible range
(limits msleep()'s timeout to 35 minutes).

We had a program (Cassandra) doing poll() with a timeout of 2 hours,
which caused msleep to think we gave a negative timeout.

This patch reduces hz to 1,000, i.e., have msleep() operate in the same units
as poll(). Looking at the code, I don't believe this change will have any
ill-effects - we don't need higher resolution (freebsd code is used to
hz=1,000, which is the default there), and the code converts time units to
hz's correctly, always using the hz macro. The allowed range for timeouts will
grow to over 24 days - and match poll()'s allowed range.

Needed by JMX.

Fixes the following problem when connecting to the JVM via JMX/RMI:

ERROR 08:22:55,278 Exception in thread Thread[RMI TCP Connection(idle),5,RMI Runtime]
java.lang.UnsatisfiedLinkError: no rmi in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1878)
	at java.lang.Runtime.loadLibrary0(Runtime.java:849)
	at java.lang.System.loadLibrary(System.java:1087)
	at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
	at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.server.MarshalInputStream.<clinit>(MarshalInputStream.java:122)
	at sun.rmi.transport.StreamRemoteCall.getInputStream(StreamRemoteCall.java:133)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:142)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)

Fixes the following problem when JMX is enabled in the JVM:

Error: Config file not found: /usr/lib/jvm/jre/lib/management/management.properties
program exited with status 1
Aborted

I'm not sure about the target location of libnpt.so, but when it was under JVM
libraries, the debug agent didn't find it.

You should be able to start the debug agent as recommended with these JVM
options:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

Remote debugging through your favorite IDE should be enabled.

Add a "qcow2" target to Makefile that uses "qemu-img convert" to build a
smaller qcow2 image out of the OSv raw image.

the musl implementation immidiately issues a DNS query, instead of looking
first at the /etc/hosts file, this patch fixes it.

As a side effect, the long boot duration is shortened by 3-4 seconds.

Command line option: --trace-backtraces

This patch implements GSI interrupt support for Xen bus.
Needed in Xen environments w/o vector callbacks for HVM.
One example of such an environment is Amazon EC2.

This is a test for the effectiveness of our scheduler's load balancing while
running several threads on several cpus.

A full description of the test and its expected results is included in
comments in the beginning of the code. but briefly, the test runs multiple
concurrent busy-loop threads, and an additional "intermittent" thread (one that
busy-loops for a short duration, and then sleeps), and expects that all busy
threads will get their fair share of the CPU, and the intermittent thread
won't bother them too much.

Testing the current code, this tests demonstrates the following problems
we have:

1. Two busy-loop threads on 2 cpus are 5%-10% slower than just one.
   This is not kernel overhead (profiling show 100% of the time in the
   test's inner loop), and I see exactly the slowdown when running this
   test on the Linux host, so it might be related to the host's multitasking?
   For now, let's not worry about that.

2. Much more worrying is that the intermittent thread sometimes (in about half
   the tests) causes us to only fully use one CPU, and of course get bad
   performance.

3. In many of the tests involving more than 2 threads (2 threads +
   intermittent, or 4 threads) load balancing wasn't fair and some
   threads got more CPU than the others.

Later I'll send patches to fix issues 2 and 3, which appear to happen because
the load balancer thread doesn't run as often as it should, because of vruntime
problems.

Pass the "-D" command line options that are used to configure JMX, for
example, to the JVM.

XAPIC is supported as a fall-back when X2APIC is not available

Nobody cares about vma address and it's easy to confuse it to the vma start address so drop it from "osv mmap" output.

Suggested by Nadav Har'El.

Strangely, C++11's new std::chrono::system_clock::now() (which I wanted
to use in a test case) calls clock_gettime() not through the function,
but with the syscall() interface. So add support for that too.