Re: [Minios-devel] [Notes for xen summit 2018 design session] Unikraft: Design and Use Cases

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hi all,

thanks also to Dario from my side.
See my comments inline.

On 09.07.2018 15:11, Florian Schmidt wrote:
> This is the summary of the Unikraft design session at the Xen summit. 
> Many thanks to Dario for taking the notes! There are some open questions 
> about future steps regarding the use of unikraft to replace MiniOS for 
> XenStore and PVstub domains.
>
>
> Goal of the session:
> clarify Unikraft's design and collect ideas/proposals for practical 
> use-cases.
> -Use-cases upstream xen-project cares (a lot) about [from Dario & Wei]
>   * replacing miniOS & (in general) stubdom code/build system
>   * example 1: Xenstore domain
>   * example 2: QEMU (traditional & upstream) stubdomain
>
> - Requirements (for 'Unikrafted' Xenstore & QEMU)
>    * must be identified
>    * Xenstore & QEMU traditional ==> newlib
>    * Unikraft has already an (although not 100% complete) newlib ==> must
>      check if it's enough
>    * QEMU upstream requires glibc ==> more difficult
The NEC team discussed about adding musl support to Unikraft recently. 
We think it might be easier to achieve than glibc. Does anyone know if 
this would enable QEMU upstream support as well?
> - What is missing
>    * LWP, sockets, file descriptors: they're there
>    * net & block: still missing
>    * net judged to be more important: netfront and virtio under review
Yes, we are currently working on networking. An early version with lwIP 
with Xen and KVM support should be available upstream in Aug/Sep.
> - Building Unikraft unikernels:
>    * is it necessary to modify source code of the app? _NO_
>    * it *may* be necessary to modify source, if, e.g.:
>      + not all dependencies (libraries, etc.) are available in Unikraft
>      + app wants to interact with Unikraft build system (with #ifdef-s, 
> etc.)
>    * what needs being modified? ==> the Makefiles/build systems
>      + applies to both apps and libraries
>      + modifications to Makefiles/build systems are generally
>        straightforward
>        (simple patches, can be integrated with autotools and/or Kconfig)
>    * is it possible to "cross-compile" an app for Unikraft?
>      + yes, if deps are there
>      + fetch Unikraft, fetch the deps, patch app's Makefiles,
>        live happy :-)
>      + Makefiles changes are basically to tell the build system to pick
>        deps and libraries from Unikraft, not from system paths
>
> - Fetching/trying Unikraft
>    * cloning different git repositories
>      + Unikraft
>      + the dependencies
>      + the app
>    * build system has stages
>      + fetches first
>      + build afterwards
>        (avoiding fetching stuff from Internet while building!)
>    * improve things using `repo' tool
>      + will be investigated
>
> - Virtualization mode(s)
>    * PV: that's pretty popular in unikernel world in general
>    * someone working on Unikraft on baremetal (but status is unknown)
Dafna got Unikraft's KVM port running on a x86 bare metal machine. It 
can be booted through grub since Unikraft on KVM uses the Multiboot 
header. She currently upstreams VGA console support so that you are able 
to build a Unikernel that prints to the screen and not just to the 
serial port.
>      + interesting (apparently) for HPC
>      + when/if done, a baremetal Unikraft app can work as a PVH/HVM guest
HVM, yes. However, I expect PVH support may go as extension to the 
current Xen PV port.
> - Steps Forward/Actions
>    * start with Xenstore domain: easy to test, e.g., everything is
>      already there to have one (SUSE shipping with a Xenstore domain
>      by default)
>    * cxsentord / oxenstord? Latter better, but needs OCAML. Let's start
>      with former
>
> [Question: advantages of xenstore in a domain?
>   Security (less stuff in dom0), scalability, disaggregation, restartable
>   dom0 (in the long run)]
>
> [Question: is Unikraft used in industry?
>   Not sure. Unikernel in general certainly have of potential use cases.
>   Unikraft is still under development. EU project with industrial 
> parteners]
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel