Does it make sense to support new features for this minimalist type 2 hypervisor? I have tried to support the loading of initrd for kvm-host. Until now, by setting the e820 memory map and load initrd to the right place, this patch makes the booting of Linux on kvm-host more progress.

The following image shows the last message for the booting of Linux after this patch. What needs to be mentioned is that there's still many warning/error happened during the booting process, we should fix them in the future.

By the way, to support initrd for Linux, I tried to turn on the CONFIG_BLK_DEV_INITRD and CONFIG_BLOCK in tiny.config and use the config to compile Linux first. But it still can't work when only enable them. Some reports like Kernel panic - not syncing: No init found. Try passing init= option to kernel. still happen. So I turn to use the default config for x86 (by make x86_64_defconfig) in this patch.

This PR is related to #4.

The problem of serial implementation is: If no condition which should be handled happens, VM will always run inside the loop of KVM_RUN ioctl. To solve the issue, the previous solution of kvm-host is using another thread to handle serial input. On the other hand, another solution is using a timer to periodically return from KVM_RUN ioctl. The latter solution may not certainly be more efficient. For example, although no POSIX thread is needed for the latter solution, the timer interrupt may cause extra cost if we return from KVM_RUN ioctl without anything that needs to be handled.

But if we only consider the simplicity, the latter solution seems to be indeed better. So we change the implementation for such reason now.

This patch implements more emulation of the serial UART. Therefore, we can perform serial communications more completely, including receive information and interact with the command line for some BusyBox Unix utilities.

There are some options for implementation which could be discussed according to your decision of the development of this project:

• The implementation of UART now could be more complete or simpler. It depends on what we are going to do with the loading kernel image.
• You mentioned the possibility to use coroutine instead of thread to implement UART. However, I'm not sure if it is worth for our current requirements:
  • If no condition (e.g. interrupted by I/O) which should be handled by our program happens, VM will always run inside the loop of KVM_RUN ioctl. If we want to yield the control back from KVM_RUN ioctl for the coroutine, we may need more mechanisms (e.g. timer?) to achieve this. So things would become harder.
  • The task of the created thread is very simple now. If there are no other tasks (e.g. other hardware emulation), I'm not sure of the necessity of the coroutine. Coupling with there are many ways to design for coroutine mechanism, I can't decide for the best implementation for this project.

The support of the virtio-blk device enables Guest Linux to access the disk image in Host. It passes the test on ext4 file system.

We also introduce virtio-pci and virtq which can be utilized by other virtio devices just like virtio-blk.

This PR is going to solved #4, and some of the discussion and where this comes from can be found in #5.

The problem of serial implementation is: If no specific condition which should be handled in userspace happens, VM will always run inside the loop of KVM_RUN ioctl in kernel. The user's keyboard inputs can't make it return from kernel directly.

To solve the issue, the previous solution of kvm-host uses another worker thread to handle serial input itself, which will need an extra mutex because it will access the VM-related data. However, under the implementation, we can't manage the code flow of main thread and worker thread narrowly, since they'll schedule by our operating system. And we also need to carefully define the critical section for both the performance and correctness.

Because of those reasons, this patch makes a reimplementation. Now, although we still need a thread for kvm-host, the worker thread doesn't access the VM-related data. Instead, it just "tells" the main thread that it needs to spend some time for the serial inputs first by signal. So we don't need to worry about data race under this design, which makes everything simple. And we can also improve the cooperative because now we can decide the code flow between serial input and KVM instead of partially depending on the operating system.

tinybox is a neat tool for hosting KVM guests. Its 8250 serial implementation uses poll(2) along with kvm__irq_line for efficient handling. There is no POSIX thread needed. We might rework the existing 8250 serial in kvm-host.

I try to use getopt to build a standard mechanism to parse command-line options, so it would be more easily to add new option in the future. This patch also makes the initrd input to be optional, since it is not indispensable for kvm-host. README.md is also changed accordingly for the new command-line interface.

The design of the command-line interface is just my favorite style, but I'm not sure if there's any insufficient. Please tell me if there's any bad implementation that should be revised.

In #9 , we have an abstraction of bus device with read and write method now. Since we have PCI and UART device emulation now, and there could be more in the future. We should integrate them with the same abstractions.