hannes/hannes.robur.coop
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

.

Browse source
This commit is contained in:
Hannes Mehnert 2016-07-21 22:44:58 +02:00
parent f48a48683b
commit f9906b4112
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
Posts/Solo5
View file

@ -15,7 +15,7 @@ Xen is a hypervisor, providing concrete device drivers for the actual hardware o
Since 2005, Intel CPUs (as well as AMD CPUs) provide hardware assistance for virtualisation (the VT-x extension), since 2008 extended page tables (EPT) are around which allow a guest to safely access the MMU. Those features gave rise to much smaller hypervisors, such as KVM (mainly Linux), [bhyve](http://bhyve.org) (FreeBSD), [xhyve](http://xhyve.org) (MacOSX), [vmm](http://undeadly.org/cgi?action=article&sid=20150831183826) (OpenBSD), which do not need to emulate the MMU and other things in software. The boot sequence in those hypervisors uses kexec or multiboot, instead of doing all the 16 bit, 32 bit, 64 bit mode changes manually. Since 2005, Intel CPUs (as well as AMD CPUs) provide hardware assistance for virtualisation (the VT-x extension), since 2008 extended page tables (EPT) are around which allow a guest to safely access the MMU. Those features gave rise to much smaller hypervisors, such as KVM (mainly Linux), [bhyve](http://bhyve.org) (FreeBSD), [xhyve](http://xhyve.org) (MacOSX), [vmm](http://undeadly.org/cgi?action=article&sid=20150831183826) (OpenBSD), which do not need to emulate the MMU and other things in software. The boot sequence in those hypervisors uses kexec or multiboot, instead of doing all the 16 bit, 32 bit, 64 bit mode changes manually.
MirageOS initially targeted only Xen, in 2015 there was a port to use rumpkernel (a modularised NetBSD), and 2016 [solo5](https://github.com/djwillia/solo5) emerged where you can run MirageOS on. Solo5 comes in two shapes, either as `ukvm` on top of KVM, or as a multiboot image using `virtio` interfaces (block and network, plus a serial console). Solo5 is only ~1000 lines of code (plus dlmalloc), and ISC-licensed. MirageOS initially targeted only Xen, in 2015 there was a port to use rumpkernel (a modularised NetBSD), and 2016 [solo5](https://github.com/Solo5/solo5) emerged where you can run MirageOS on. Solo5 comes in two shapes, either as `ukvm` on top of KVM, or as a multiboot image using `virtio` interfaces (block and network, plus a serial console). Solo5 is only ~1000 lines of code (plus dlmalloc), and ISC-licensed.
A recent [paper](https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_williams.pdf) describes the advantages of a tiny virtual machine monitor in detail, namely no more [venom](http://venom.crowdstrike.com/) like security issues since there is no legacy hardware emulated. Also, each virtual machine monitor can be customised to the unikernel running on top of it: if the unikernel does not need a block device, the monitor shouldn't contain code for it. The idea is to have one customised monitor for each unikernel. A recent [paper](https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_williams.pdf) describes the advantages of a tiny virtual machine monitor in detail, namely no more [venom](http://venom.crowdstrike.com/) like security issues since there is no legacy hardware emulated. Also, each virtual machine monitor can be customised to the unikernel running on top of it: if the unikernel does not need a block device, the monitor shouldn't contain code for it. The idea is to have one customised monitor for each unikernel.
@ -38,7 +38,7 @@ cp x86/float.h x86/_stdint.h x86/stdarg.h x86/endian.h x86/_types.h $TMP/x86
cp float.h osreldate.h stddef.h stdint.h stdbool.h stdarg.h $TMP cp float.h osreldate.h stddef.h stdint.h stdbool.h stdarg.h $TMP
``` ```
A bunch of opam pins are needed (using pins instead of the [solo5 repository](https://github.com/djwillia/opam-solo5/) since pins are local to compiler switches, whereas repositories are global, and I needed to modify some bits anyways): A bunch of opam pins are needed (using pins instead of the [solo5 repository](https://github.com/Solo5/opam-solo5/) since pins are local to compiler switches, whereas repositories are global, and I needed to modify some bits anyways):
```bash ```bash
opam pin add -n solo5-kernel-virtio https://github.com/hannesm/solo5.git#FreeBSD opam pin add -n solo5-kernel-virtio https://github.com/hannesm/solo5.git#FreeBSD
opam pin add -n ocaml-freestanding https://github.com/hannesm/ocaml-freestanding.git#FreeBSD opam pin add -n ocaml-freestanding https://github.com/hannesm/ocaml-freestanding.git#FreeBSD
@ -90,9 +90,9 @@ I have not yet played with network, TLS, and other things...
## Open issues ## Open issues
- There are several things to upstream, such as the clang changes and FreeBSD support for ocaml-freestanding and other libraries - There are several things to upstream, such as the clang changes and FreeBSD support for ocaml-freestanding and other libraries (see [this tracking issue](https://github.com/Solo5/solo5/issues/61)
- The `Makefile` generated by mirage should be in the intersection of BSD and GNU make - The `Makefile` generated by mirage should be in the intersection of BSD and GNU make
- I'm not happy to require `ld` from the ports (but the one in base does not produce sensible binaries with `-z max-page-size=0x1000` [related](https://github.com/djwillia/solo5/pull/56)) - I'm not happy to require `ld` from the ports (but the one in base does not produce sensible binaries with `-z max-page-size=0x1000` [related](https://github.com/Solo5/solo5/pull/56))
- I'm also not happy to copy around include files and depend on gcc just for `stddef.h`, is there any sensible way to have freestanding includes? Should `-nostdinc` be used? (It looks necessary on Linux). - I'm also not happy to copy around include files and depend on gcc just for `stddef.h`, is there any sensible way to have freestanding includes? Should `-nostdinc` be used? (It looks necessary on Linux).
- Via [twitter](https://twitter.com/bhyve_dev/status/748930600581492736), bhyve devs suggested to port ukvm to ubhyve. This is a great idea, to no longer depend on virtio, and get more speed. Any takers? - Via [twitter](https://twitter.com/bhyve_dev/status/748930600581492736), bhyve devs suggested to port ukvm to ubhyve. This is a great idea, to no longer depend on virtio, and get more speed. Any takers?
- Debugging via gdb should be doable somehow, bhyve has [some support for gdb](https://wiki.freebsd.org/bhyve/DebuggingWithGdb), but it is unclear to me what I need to do to enter the debugger (busy looping in the VM and a gdb remote to the port opened by bhyve does not work). - Debugging via gdb should be doable somehow, bhyve has [some support for gdb](https://wiki.freebsd.org/bhyve/DebuggingWithGdb), but it is unclear to me what I need to do to enter the debugger (busy looping in the VM and a gdb remote to the port opened by bhyve does not work).