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.

The correct fix is to add setup_features call in the constructor

This reverts commit db65a9fe.

We need to read the various config bits from the device config, not the
guest config.

Without this we get errors reading/writing from larger imageṡ.  Our current
10g usr.img actually is enough to trigger this, but our lack of error handling
papered over it so far.

Once all the bugs vs I/O error handling in virtio-blk are fixed we'll
actually need this.

Disk alloc is a simple function that, well, allocates a disk. It is supposed
to be provided by the device code, but for simplicity I am providing it in
blkfront itself. We have no really better way to put it: device.c is quite generic,
and we seem to have no disk specific file.

If time brings us more users of such function, then I will move it somewhere else.

Xenbus will use BSD taskqueues in the following way:

  taskqueue_enqueue(taskqueue_thread, &xbs->xbs_probe_children);

taskqueue_thread seems to be the main bsd taskqueue, which wasn't ported in our
initial port. So I am definiting it and initializing.

It seems a bit odd to do this in net.cc, but this is where the rest of the BSD
initialization lives anyway (maybe the filename should change?). Let me know if
you feel strongly about it, and I will change. But for me it is okay for now.

BSD devices will use more state than we currently have. Extend the current
device to cope with that.

BSD uses more flags than we define. This patch defines the aditional missing
flags.

Those are the verbatim files, straight from BSD.

BSD register a structure with its per cpu data. We can do the same, using
just the fields we need.

Here are some compile-time definitions that will make importing of BSD code
easier. They should be straightforward and trivially true for our current
setup: x86_64 is our current arch (and when we support others we can just replace
the static -D__x86_64__ with a test that goes precisely here, it makes no sense
to support code that is not SMP, and the id string is included by pretty much
every BSD file - and I believe we have no interest in that.

Xen BSD code will attempt to create processes to serve as deamons for xenstore.
We can basically emulate this by creating threads.

The only thing I am doing differently from the already existent thread creation
layer that we have, is that callers will expect a struct proc to be returned. We
had this as a stub, now I am creating a small struct with just the PID to serve
as a return placeholder. The listener processes in xenstore never dies, so I am
not implementing a deallocate routine for them