We will use it in our bus_dma implementation

Our version of biodone takes two arguments instead of one. Adjust it, passing
the status in the second argument as expected. We could adjust our biodone()
function to be the same as BSD's, but I decided to do the other way around, at
least for now: we need locking and synchronization via cond vars at bio
completion, and although the xenfront driver has its own lock for this, the
other users rely on the internal lock for correctness. Adjusting them would
mean adjusting their locking semantics, which although doable, is just more
work than adjusting xenfront.

We need to add our headers first, but the rest should be ready to go.

It provides very simple queue / dequeue functions for the bios.

This is used by subr_disk during bio flush operation

With all the infrastructure in place, we can compile all our xenbus code in,
and enble the netfront driver.

BSD code does not initialize its structures.. It works well when memory is
previously zeroed but not otherwise. Xen hypervisor compiled in debug mode
fills memory with a poison pattern, and then the code breaks for those
variables. Force them to 0.

We need bsd/ directory listed in includes not only for bsd/ files, but
for our cpp code as well. So it has to be in the main includes.

Second, I was overly optmistic about the interface version. The drivers
expect an inteface version slightly older than the maximum present in headers.

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.