condvar_wait() expects an absolute time, not a duration.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Spotted by GCC with '-Wformat=1':

../../drivers/xenfront-xenbus.cc: In function ‘XenbusState xenbus_get_state(device_t)’:
../../drivers/xenfront-xenbus.cc:219:80: warning: format ‘%d’ expects argument of type ‘int*’, but argument 6 has type ‘XenbusState* {aka xenbus_state*}’ [-Wformat=]
     xs_scanf(XST_NIL, dev->get_node_path().c_str(), "state", NULL, "%d", &state);

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Add Cloudius copyright and license statement to drivers/*.

A couple of header files were based on Linux's BSD-licensed header files
(e.g., include/uapi/linux/virtio_net.h) so they included the BSD license,
but not any copyright statement, so we can just replace that by our own
statement of the BSD license.

This patch implements GSI interrupt support for Xen bus.
Needed in Xen environments w/o vector callbacks for HVM.
One example of such an environment is Amazon EC2.

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.