Needed for libstdc++ from gcc 4.8.1

It doesn't exist there.

[ glommer: use the alternative system ]

To make matters even clearer, enclose the main alternative macro in a
xen-specific macro, so we don't have to code xen's presence condition
everywhere.

I am proposing, with this patch, a very simple alternative system to serve as a
basis for xen pv operations. The end goal is to patch the performance critical
instructions in, but I will defer it until later since this is a performance
optmization. Let's get that working first.

However, I figured that if we are already writing the xen pv code enclosed in
some kind of macro, then when we do patch, we won't have to change anything.

That said, I don't expect to have a lot of pure pv users - It is 2013, and even
VMWare discontinued their vmi, leaving Xen as the only relevant player. We
don't need, then, a fully featured core-pv ops like Linux. This system of
alternatives is simple enough to accomodate xen, and it works by providing two
code blocks and a condition. The first block is executed if the condition is
false, and the second if the condition is true.

For future reference, note that we can use when patching by doing something
very similar to Linux jump labels: we replace the branch with a jump
instruction that just jumps to the right place (taken or not-taken part).  This
brings simplicity and runtime efficiency at the expense of a little bit more
icache pressure.

Add a xen_init() function (currently only stores the start_info pointer)
and jump to the normal init sequence.

[ glommer: rebased to current tip ]

This metadata identifies the kernel to Xen and enables the pv loader.

[ glommer: adjusted to current tip and fixed header include ]

Now that we have everything in place, ask the loader to be able to probe the xenbus.

The xen block driver needs some extra state not needed for the network drivers.
Namely, the same way virtio-blk does, we need to tell the block layer which is
our strategy, read and write functions. For that, we need some extra code that
I am implementing in xenfront-blk.cc.

BSD expects its sector number to be already provided by the bio. We could add this field
to the bio, but it is easier just to calculate it from the given offset.

There are many places in which the bios are filled up, including many in the zfs code. So
it is easier to change them just here.

Simple implementation of BSD's bus_dma interface. Since we are constrained by virtual
environments, we are able to cut out most of the things.

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.