Christoph discovered a bug in our dynamic linker, where symbols which
exist in the kernel cannot be used in a shared object, which can
cause nasty bugs when trying to run existing programs.

This test demonstrates this bug, and verifies its fix (in the
previous commit).

This patch fixes the bug in tst-resolve.so, where an OSV symbol (such as
debug()) hides a symbol in the application (a shared object we are running).

We look up symbols in load order - if tst-resolve.so needs libstdc++.so, we
search for symbols in this order - first in tst-resolve.so and then
libstdc++.so. This order is mostly fine. There is one problem though - that
OSV itself is loaded first, so always gets searched first, which is not
really what users expect: Users expect OSV to behave like the glibc library
(searched last), not like the main executable (search first). So this patch
keeps the first-loaded object (OSV itself) last on the search list.

Pass -X* (and of course also -XX*) options to the JVM.
The -Xmx option is the most useful example.

The JVM options end with the first "-jar" *or* classname, not *and*.
Fix the typo.

Now that vn_stat() supports VOP_GETATTR, wire up the ZFS implementation.

Without this we somehow get a non-zero value in it while running under OSv.

This needs to be investigated as it would have a bad effect on user workloads.

The off_t cast are just superflous, the int cast causes actual truncatation
bugs.

This currently causes an abort with out implementation, which looks ugly.

Just let the return 0 from main do its work.

We don't support writing through shared mmaps yet.

Add fsx from xfstests to our test cases.

Currently fails on the first OP due to our lacking truncate implemenation.

gcc generates some functions in their own section.  Have a wildcard that
catches all of these sections so they can all be merged into the global
.text section; this makes 'perf kvm top' format its output better.

The catch-all wildcard is placed last since ld uses the first match.

Not all machines have Enhanced REP MOVSB/STOSB (ERMS); provide optimized
fallbacks.

Cache uma initialized objects to avoid re-initializing them on each allocation.

Convert poll.c to poll.cc, and add a few tracepoints.

Before this patch, we ran init.js for every new shell. But init.js runs
things that only need to be done once - like setting the IP address or
runnig a DHCP or Telnet server - and we don't need to do this again when
somebody telnets in.

So this patch adds an "init" flag, which tells the shell if it should
read init.js. This flag is true for the CLI's main(), but when run from
TelnetCLI, the flag is false.

Our CLI changes the console's tty mode to raw when doing its line
editing, and back to the original (cooked) mode when running a command.
Obviously, when we're running on a telnet connection we shouldn't touch
the console's mode like the existing code did.

OSV doesn't (at least for now) have ptys, so we can't handle the
telnet connection exactly like we handled the console, and the kernel
can't implement a "cooked" line discipline for us like it implemented on
the console. But we can do a very similar thing in Java instead:

This patch adds a new Java class, "TTY", which has an input and output
stream and an "stty" interface. We have one implementation for the console
(using System.in, System.out and the console's Stty), and a different
implementation, TelnetTTY, for a telnet connection.

This patch does not currently implement a line discipline ("cooked mode")
for this TelnetTTY, so it will always stay in raw mode. This is fine for all
our current uses of the CLI, but if in the future we have commands that read
user input and expect cooked mode (echo, line editing), we'll need to
implement this line discipline.

There is no harm in leaving it mappend, and there is a potential harm in unmapping,
since our mapping code does not keep reference counters. So if we map an already
mapped area, the unmap code will just unmap it for good. Avi spotted this.

We are currently using PCI's brute force enumeration, which consists of scanning
all possible combination of b,d,f. This makes us issue many inb operations, a lot
more than we could do if we were using smarter enumeration. In my system, the inbs
alone account for more than 5M cycles, which takes around 4s to run (remember this
is xen, it is faster in KVM)

We can do a lot better by using recursive discovery, and only scanning the buses
we need to. In the case of virtual systems the difference is even bigger, since it
is very unlikely that we will have any complex setup with more than one bridge.

Boot for me feels instantaneous now (once we get to start OSV)

The init and fini functions are fairly expensive (for networking).  Cache
initialized objects in percpu pools to save this cost.

The implementation is imperfect since if we're allocating on one cpu and
freeing on another, reuse is low.  This can be improved in the future, or
made unnecessary with VJ rings.

Increases netperf from ~14.6Gbps to ~17.8Gbps on my machine.

M_ZERO requests zeroing of the object regardless of any constructor; honor it.

It works now because we bzero() all objects unconditionally, but we soon
won't.

We're going to make zones more expensive to allocate, so allocate only
as many as we need.

Allows integrating with our mempools.

dynamic_percpu<some_large_struct> will exhaust our percpu pools very quickly.
dynamic_percpu<unique_ptr<some_large_struct>> works, but is awkward to
construct (need a cpu notifier so we allocate it for newly onlined cpus).

Add dynamic_percpu_indirect<some_large_struct> which will allocate an
object for each cpu automatically as it is brought up.  It's not
completely general as we can't pass any constructor arguments, but should work
for now.

M_ZERO requests zeroing of the entire mbuf, which clears the fields initialized
by the init function.  It only works now because we don't honor M_ZERO.

Remove M_ZERO and replace with bzero() for the packet data only.

The trace object contains a list link for the hash table, which needs to be
initialized by the constructor.  However, trace_alloc() did not call the
constructor and returned uninitialized memory.

Fix by calling the constructor.  For simplicity, all of the object's
initialization is moved to the constructor.

I have recently ran into an early init bug due that ended up being tracked
down to a changeset in which the initialization priorities of the constructors
were changed. One of the changed ones was kvmclock, but the change did not
update kvmclock.

I propose we use constants for that. To avoid things like this in the future,
wherever priorities are used, I believe they should come from the same place
so that the order is utterly obvious. To handle that, I am creating the prio.hh
file, and sticking all priority definitions in there.

So after all the BSD code is not buggy, it is just their semantics that is
slightly different from our version of mlock (Thanks Christoph). Whether or not
we will drop the lock will be controlled by the value of the PDROP flag.

Our msleep queues are protected by an internal lock which is not the same lock
the user passed to the msleep call. Therefore, we can just a version of
wait_until that does not take a lock argument, and do the locking manually
ourselves. We may then lock it back or not, depending on the presence of the
PDROP flag.

Only those I plan to use for now. Wrap it into __*_DECLS

This provides a simple msleep implementation that simply calls our own, and
an empty MTX_INIT macro

Most of those files are quasi-empty (just with the usual .h ifdef in case we need
to add things later). When relevant, we also add code to those files, sometimes
including our own files, and providing extra definitions.

Providing those stubs make importing BSD files a lot easier.

This allows gcc to infer that asserts usually do not trigger, and move all
that code out-of-line.

This patch adds a simple telnet server to OSV, implemented in Java.
One can telnet to the VM's IP address (default port 23) and get a CLI
shell. Multiple concurrent telnet sessions are supported (and the shells
are independent, as expected).

To start the telnet server, simply run the com.cloudius.cli.util.TelnetCLI
class. For example, in the CLI to start a telnet server in the background
use:

	java com.cloudius.cli.util.TelnetCLI &

To start OSV with only a telnet server, try

	sudo scripts/run.py -c1 -nv -m2G -e "java.so -jar
		/java/cli.jar java  com.cloudius.cli.util.TelnetCLI"

(The "cli.jar" in the last example is only needed to set the IP address...)

In the future we can turn the telnet server on by default - but let's
add a password feature first :-) Right now, there's no password requested
when someone telnets in.

The CLI used to assume it was using System.in, System.out (which point
to the console). Now make these parameters. We need this so we can run the
CLI on a telnet connection, and it doesn't send output to the console or try
to read from it.