The point of this commit is that the heap allocated for the guest may
not be all that the host has allocated for the guest. In other words, we
could exclude a certain portion that is always accessible to the guest
and ensure that the stack starts after this portion. Furthermore, the
stack (SP) will start from guest_mem_size and there may potentially be a
portion between guest_mem_size and mem_alloc_size.

0x0          guest_mem_size <|      |> mem_alloc_size
 |---------------------------+------+
 | kernel + heap -> <- stack | ring |
 +---------------------------+------+
                          SP ^

With regard to this pull request, we would like to place the shared ring
between the guest and the host on this portion (so that it is accessible
by both and shared).

We consider this invariant to always hold true:
guest_mem_size <= mem_alloc_size

Our ring is a fixed structure containing two queues:
- a queue for the guest to send operations to
- a queue for the host to confirm operations

The main idea is that the two queues are shared between the guest and
the host and are located in an area allocated to the guest (so that the
guest can access them).

The second idea is that these queues are shared by two processes running
in parallel (hence the use of memory barriers). These barriers can be
found, for example, in our VirtIO support.

The third idea concerns the 'kick'. The host thread can wait for new
entries. It will therefore inform the guest that it needs to be woken up
via the kick value (if it is set to 1).

The final idea is cache-line alignment (64 bytes). The guest generates
entries and consumes commits when the host generates commits and
consumes entries. We can physically locate what the guest modifies and
what the host modifies on different cache lines to avoid false sharing
between the two CPUs (that of the guest and that of the host thread).

This commit introduces two fields that allow us to specify the features
the host has implemented and what the guest can handle. For the time
being, only the `host_features` field is used in our pull request.

Here, we implement the functions used to notify the host. For KVM, an
ioeventfd will be associated with the address RING_KICK_PIO_BASE. For
FreeBSD/OpenBSD, this will be a genuine VM-exit.

We define a pipe (2 file descriptors), our thread that will perform the
read()/write() operations, and our ring. We catch the signal from our VM and
write to our pipe.

<machine/vmm.h> is added also due to an error for an incomplete vm_run.

We define a pipe (2 file descriptors), our thread that will perform the
read()/write() operations, and our ring. We catch the signal from our VM and
write to our pipe.

Here, we just define our ioeventfd file-descriptor and our ring. The
kick mechanism differs from that used in OpenBSD/FreeBSD. Here, we use
IOEVENTFD, which we initialise at the address RING_KICK_PIO_BASE. When
we wish to perform an `out` operation at this address, KVM will
automatically write to the file descriptor.

We statically allocate the buffers that will contain our Ethernet
frames. When writing, we notify the host and do not wait for the result.
As for reading, we notify the host and wait for the commit (we want to
be synchronised with our host’s thread). These operations only occur if
net_ring is not NULL (which is the case if the FEATURE_RING_IO feature
is advertised by the host).

This function allows you to allocate a ring within the memory area
allocated for the guest. This ring is used by all network interfaces.

Preparing our ring for our virtual machine before the CPU initialises.
This function must be called beforehand, as it changes `guest_mem_size`
(relative to `mem_alloc_size`), where the SP register must be placed.

Here, we create a thread that will handle the read()/write() operations
received (from the guest) via the shared queues.

The first value used by our thread is: ta->ready. This ensures that the
dom0 waits until the thread has actually started before applying certain
security measures such as pledge (for OpenBSD).

Next, our thread iterates 4096 times initially to 'wait' for an action.
If, despite this 'wait', we still have no inputs, we block on reading
the file descriptor (the ioeventfd for KVM or the pipe for
FreeBSD/OpenBSD) and signal to the guest that we need to be 'kicked'.

Finally, we execute the write() and read() operations without blocking.
If a write fails, we fail the operation (as we did before). For the
read(), we pass the error to the guest.

Finally, we register a hook to ensure our pthread terminates correctly.

Here, we are essentially setting up the `notify_fd`, which will allow us
to kick the thread we are also creating. For KVM, this is where we
associate the file descriptor with the address `HVT_RING_KICK_PIO_BASE`.
For OpenBSD/FreeBSD, we properly allocate our pipe.