Those headers are needed from blkfront and netfront. Some of them are empty stubs
are usual but some are import from BSD. I am bringing them separately so it is
obvious what they are here for.

The macro to calculate ring size are really gigantic and nested. Somewhere,
somehow, gcc believes that one of the size calculations yields a variadic size.
It doesn't seem to be the case to me, but maybe we are using (or lacking) some
compiler flag that can explain this.

Although this is clearly suboptimal, let us set with this for now. It should not
be a huge problem unless we update xen headers.

Because softc is private - only a void pointer outside blkfront, we need
a helper here to return the correct device from its softc representation.
This will be used by the osv side to determine where to trigger IO to

BSD uses non-standard device names (standard here meaning us) for the network
and block interfaces. There is no reason for us to play the complexity to deal
with different names, so change it.

This patch contains the trivial osv adjustments for osv, like type fixing,
header conciliation, sysctl removal, etc.

We won't implement interface media change routines - at least for now, so stub
them.

Those are: type conciliation, osv porting header inclusion and deleting unused
statements.

There are many other bio fields and functions that blkfront uses that are
not provided by our simplified bio. I am adding them here. One of the things we need is
a type definition of daddr_t. This already exists in fatfs.h, but it makes more sense to
live in the lower level code. So instead of including fatfs in bio.h, I am including
bio.h in fatfs and moving the daddr_t definition here.

Current test does:

    (((ifq)->ifq_drv_len == 0) && ((ifq)->ifq_len == 0))

but ifq_drv_len does not exist. Funny enough, it does not exist in BSD
basic interface queue as well.

Some block devices, such as the Xen blkfront, will have a maximum per-request size
that needs to be obeyed. In order for us to do it, we'll need to be aware of this
requirement in upper layers. So set up the device with it. We initialize the default
structure to make sure only interested parties need to set this up.

For xen, I would like to use an already existing device instead of creating one.
I still need to register it, though. I am here factoring out device_create in
a allocation and a registering part so I can use the later by itself.

This commit includes the basic translation layer so we can support BSD devices
for Xen as is. I believe there is room for improvement, but that provides a
very good starting point. I would like to provide you guys with a smaller
commit, but it is quite cumbersome to separate the device implementation from
the bus implementation per se. Part of it is due to the way Xen does things.

For instance: when we are talking virtio devices, each of them will have its
own pci device. For xen, only one pci device will be exposed, with its own
interrupt, and that will be the xenbus. The xenbus is then responsible for
querying the xenstore and figuring out which devices are there. Maybe there
is a different way of doing things (I believe for instance that there is no
reason to have shared interrupts between all devices) but that is the way BSD
does things. And about the bus-is-the-device, even Linux as far as I know.

Another thing to note, is that BSD devices registered with a device_method_t
seem to be fully hierarchical. I am not doing it this way here (I am mostly
ignoring the xenbus device_method_t definitions), which means there are a lot
of assumptions that probably won't hold with other kinds of drivers. But it
should not be hard to extend, and that simplifies things.

By issuing this hypercall, we can control where xen delivers the interrupt to.
Right now we will only support vectored callbacks. It should not be hard to extend
this for gsi and intx for HVM guests.

If we have this array, BSD code that checks for features can run unmodified.

Changes needed for xenbus operation. They are, as usual:
* delete function tables and make previously static functions on it public
* comment out sysctl code
* change order of includes between sbuf.h and malloc.h. sbuf calls into our
  functions, and those have a single malloc instead of a 3-argument one. This
  is by far the easiest way to handle this
* Modify calling convention for device_add_child. It is just way easier if we
  now the path at creation time. BSD does not need it because it creates all
  devices equal (they are the same device_t structure), but for us is way more
  convenient if we can create the appropriate classes.

In particular, I am not implementing the struct filling in the end of
the file. Just comment it out, and make the relevant static functions
public. We will call them from our code.

As suggested by Guy

Mostly trivial changes needed to compile the pv event channel.  We need some
type adjustments, but the most complex ones are assembly fixes.  Because BSD
seems to only do this for 32-bit guests, we need to adjust the inline asm
instructions to take quad words for longs, and force int types for double
words.

After this, the evtchn can be compiled.

This file implements the pv and pv-on-hvm event channel mechanism.
Verbatim copy from BSD.

The BSD pv event channel will expect the underlying OS to be able to register a
PIC.  For now we will just allow that for xen, and provide the expected
translation functions to allow xen to work.

The design I have chosen is to let the xen event handler run in interrupt
context. We can do threaded if it really becomes a problem, but right now it
should do. The handlers themselves, though, will be threaded. So the
intr_execute_handlers() function will do nothing more than to wake the
respective threads.

BSD will provide us functions, not threads. So we have a common thread that
executes the function that we were given. One exception for this is the xenstore.
The xenstore is already threaded, and its interrupt handler will also just wake
up a thread. So for that we could do better in the future.

This contains interrupts, devices and bus definitions. Most of them are is bus
files in BSD anyway.

With this patch, the grant table code is compiled into osv.
The edits in the file reflect the fact that we don't need to go through PCI
memory for the Xen special device even for HVM. We have mappings that are
way simpler, so we can just use them. All the rest is kept as unchanged as I
could.

Xen files in BSD (and Linux for that matter) expect a variable called
HYPERVISOR_shared_info that points to the hypercall page - that in our case is
statically defined. So we just need to point it with the correct name to our
shared info page.

Note the type mismatch: we are defining our own xen_shared_info to be able to
access some parts of the structure, like the wallclock, more conveniently.
Because of that, we need a type cast.

Xen does not need to EOI. At least not with the APIC anywyay: it signals
end of interrupt by flipping vcpu_info->evtchn_upcall_pending to 0, but
that is already done by the BSD handler, so we might as well do nothing.

Avi generalized the irq handler to have a pre_eoi and a handler, and in
this patch I am taking the extra step of adding an EOI indirection as well.

This is for the lack of a better place.

Already specified elsewhere.  Noted by Nadav.

The release build optimizes away references to this object, but the debug
build does not.  Define it.

We don't initialize the dhcp packets, so some of them get the relay agent IP
set, and the DHCP DISCOVER packets get sent to a random address on the
Internet.  Usually it doesn't have a DHCP server installed, so the guest
does not get configured.

Fix by zero-initializing the packet.

Currently, looking up a non-existing tracepoint kills the guest:

sun.org.mozilla.javascript.WrappedException: Wrapped java.lang.RuntimeException: Cannot find tracepoint (/console/perf.js#91)
	at sun.org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1786)
	at sun.org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:202)
	at sun.org.mozilla.javascript.NativeJavaClass.constructSpecific(NativeJavaClass.java:284)
	at sun.org.mozilla.javascript.NativeJavaClass.construct(NativeJavaClass.java:202)
	at sun.org.mozilla.javascript.ScriptRuntime.newObject(ScriptRuntime.java:2440)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_7(/console/perf.js:91)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_10(/console/perf.js:114)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_1(/console/perf.js:8)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_run_sync_15(cli.js:202)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:76)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_invoke_18(cli.js:223)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName(OptRuntime.java:97)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_command_19(cli.js:237)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_main_loop_21(cli.js:290)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_script_0(cli.js:323)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:426)
	at sun.org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3178)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.gen.cli_js_21.exec(cli.js)
	at sun.org.mozilla.javascript.Context.evaluateReader(Context.java:1142)
	at com.cloudius.cli.main.RhinoCLI.run(Unknown Source)
	at com.cloudius.cli.util.TelnetCLI.handleConnection(Unknown Source)
	at com.cloudius.cli.util.TelnetD$1.run(Unknown Source)
Caused by: java.lang.RuntimeException: Cannot find tracepoint
	at com.cloudius.trace.Tracepoint.findByName(Native Method)
	at com.cloudius.trace.Tracepoint.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
	at sun.org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:194)
	... 34 more

Fix that by catching errors like "perf stat" does.

Currently we statically link to libstdc++ and libgcc_s, and also dynamically
link to the same libraries (since the payload requires them).  This causes
some symbols to be available from both the static and dynamic version.

With the resolution order change introduced by 82513d41, we can
resolve the same symbol to different addresses at different times.  This
violates the One Definition Rule, and in fact breaks std::string's
destructor.

Fix by only linking in the libraries statically.  We use ld's --whole-archive
flag to bring in all symbols, including those that may be used by the payload
but not by the kernel.

Some symbols now become duplicates; we drop our version.

Needed to link the entirety of libstdc++.a.

Needed for statically linking the entirety of libgcc_eh.a.

Reduce memory consumption so we can test in a 1GB guest.

msleep() will fault if mtx is NULL.

The test tries to acquire the write lock while the read lock is taken in the
same thread, which deadlocks.

Remove the deadlocking construct.

taskqueue_thread_enqueue expects a pointer to a pointer to the taskqueue as
context, give it that.