xen: switch from SCHEDOP_poll to interrupts + SCHEDOP_block

SCHEDOP_poll was convenient from an interface point of view, but
the interface in xen purposely restricted the nr_ports which
could be polled to 128 -- far too small for some of our more
ambitious use-cases.

We switch to SCHEDOP_block which implies:

1. the hypervisor callback will be called when an event is
   received. We don't actually need to run any handler code
   so the callback is a no-op. We must not do anything effectful
   in the callback (like printk) or we may trigger a spin.

2. SCHEDOP_block returns and the evtchn_poll function can
   query the event channel pending bits (as we did before)

We still need to:

1. set an explicit timer; SCHEDOP_poll took a timeout as a
   parameter but SCHEDOP_block blocks until the next event

2. unmask event channels to permit event delivery. This was
   not necessary with SCHEDOP_poll because it took the event
   channels as arguments.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: clear the evtchn_upcall_pending flag in the hypervisor callback

Although we aren't polling the pending bits in the callback itself,
we do need to acknowledge the interrupt so it isn't delivered
immediately again, causing a hard spin.

We rely on the facts that
 (1) after the hypervisor callback is called the SCHEDOP_block
     returns, and we will run evtchn_poll to check the pending bits
 (2) by clearing the evtchn_upcall_pending flag in the callback
     we ensure that future event notifications will trigger another
     interrupt

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: block the domain with a timeout, disable interrupts after

The call to SCHEDOP_block is careful to return immediately if
any events are pending. It also re-enables interrupts before blocking.
When SCHEDOP_block returns, we disable interrupts because we
already know there is work to do.

Configure the domain's timer interrupt before we block.

Finally, rename "block_secs" to "block_nsecs" to show that the
units are _nanoseconds_ (thanks dimosthenis.pediaditakis@cl.cam.ac.uk)

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: unmask the xenstore event channel

This is necessary now that we're using the SCHEDOP_block interface.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Add a loss-less event channel interface to Activations

Activations.wait is hard to use because if the calling thread
blocks between calls, events which arrive when the Lwt_sequence
is empty are silently dropped.

So we add a new interface which is easier to use and which
permits blocking between calls:

  val program_start: event
  val after: Evtchn.t -> event -> event Lwt.t

Applications should keep calling [after] passing in the last
[event] they have seen. The system counts the number of times
each port has been notified and knows when a call to [after]
should not block i.e. when a notification was received after
the last time [after] was called.

We can now remove the spurious wakeup hack from Activations.
This was masking bugs by waking up the device drivers whenever
there was console activity caused by printf.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: switch console over to Activations.after rather than Activations.wait

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: switch xenstore over to Activations.after rather than Activations.wait

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: switch Netif over to Activations.after rather than Activations.wait

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: bind the timer VIRQ, and unmask the channel so we get timer events.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: set default timeout to 1 day rather than 1000 days

Unfortunately 1000 days is considered to be 'too long' by xen
(1000 days > 2^50 ns) which triggers a Linux bug workaround.
This causes the timer to be set to 100ms and a debug line printed
to the xen console.

Original-patch-by: Dimosthenis Pediaditakis <dimosthenis.pediaditakis@cl.cam.ac.uk>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xen: re-enable event delivery on resume

The resume codepath is quite similar to the start codepath.
xen: Activations.after blocks until either a new event *or* a new Generation

Activations.resume() will broadcast on the condition variables of all
ports; anyone blocked in Activations.after will be woken.
Activations.after will fail with Generation.Invalid if the generation
has changed.
xen: add Activations.dump for debugging

This prints the event counter associated with each event channel.
It's useful to see which channels are 'hot'.
xen: print a message to the console if we fail with Generation.Invalid

This should only happen on resume.
xen: move the event channel query into the OCaml main loop

We now call
  Eventchn.look_for_work
    -- this safely tests the bits in the shared bitmap and updates
       the OCaml array
  Activations.run
    -- this checks the OCaml array and wakes up waiting threads
in the OCaml 'main loop'.
Merge pull request #58 from djs55/interrupts

(careful review and test required): turn on async interrupts instead of polling