Add filesystem UIO driver

[dreamliner787-9]

This PR adds:

• Filesystem UIO driver to libvmm to allow creation of Filesystem VMs. Allowing native clients to use any filesystems supported by Linux streamed in from a native block device driver.
• A dependancy to liburing.

The basic idea is:

• The client filesystem command queue, completion queue and data region are mapped into the guest's userspace via UIO.
• Then, the Filesystem UIO driver dequeues all the commands and map it into the corresponding Linux FS calls.
• Via io_uring, the driver will enqueue all the Linux FS calls into io_uring's submission queue and signal the kernel. io_uring was used to improve performance by allowing us to perform multiple I/O operations with only 1 syscall.
• The driver will wait for all SQEs (Submission Queue Entry) to complete. Then for each CQE (Completion Queue Entry), a callback is invoked to enqueue the completion message to the native client's completion queue.
• The driver finally faults on a pre-determined physical address for the VMM to signal the native FS client.

Note:

1. Not all FS calls go through io_uring. This includes:
   • Mount/unmount.
   • Truncate.
   • Directory calls (FS_CMD_DIR_*)
     For these calls, the driver will "flush" the io_uring submission queue, wait for the flushed operations to finish and invoke the required operation. Acting as a barrier to ensure correctness in mixing synchonrous and asynchronous operations.

[Ivan-Velickovic]

Why do we need a dependency?

[dreamliner787-9]

Why do we need a dependency?

It is a wrapper library around the raw io_uring syscalls that the FS driver needs, without it, we would need to manually map queues memory and manage them

[Ivan-Velickovic]

How difficult is it to do that? I would really like to avoid adding any more dependencies.

[dreamliner787-9]

How difficult is it to do that? I would really like to avoid adding any more dependencies.

It is possible, but will be time consuming, error-prone and make the code harder to read as we would have to manipulate the raw shared data structures with the kernel, submission/completion queues and its objects, and put memory barriers at the correct place for every operation.

[Ivan-Velickovic]

This driver is for LionsOS and should not be in libvmm then.

[Ivan-Velickovic]

It is possible, but will be time consuming, error-prone and make the code harder to read as we would have to manipulate the raw shared data structures with the kernel, submission/completion queues and its objects, and put memory barriers at the correct place for every operation.

Okay I'll have to have a look at how complicated it is.

[Ivan-Velickovic]

I'll close the PR since it should be going to LionsOS.

libvmm is supposed to be OS agnostic.