Xen project Mailing List

Hi, this is what we said at the meeting (2022-06-22) and we scheduled another meeting in 2 weeks (2022-07-06 14:00 - 15:00 (CEST)). Thanks for your participation.

Sorry for my english and if I missed something, please tell us through this email :) ! Enjoy.

PS: I will let Hannes send another email to schedule the next meeting.

# Mirage 2022-06-22

## Presentation round

reynir: I'm in robur :)

pierre: I'm Pierre, CS teacher (in France, Bretagne), I recently joined MirageOS. I want to use it and teach new things to my students.

thomas: continue to work on eio and OCaml 5 stuff. I plugged eio into lwt and async. It should be possible to plug into MirageOS

timada: from Japan, working on Solo5 and microcontrollers, I finished implementing 40% percent of tenders. I look into details.

## What is going on about mirage

romain: Hannes did a PR about reproducible builds and added few meta-informations into the generated OPAM files to let `orb` to build unikernels: https://github.com/mirage/mirage/pull/1335
Some works was done about `ocaml-solo5` (thx to Pierre and Hannes) to provides some metrics about allocations on the C heap (with `dlmalloc`): https://github.com/mirage/ocaml-solo5/pull/120
A release of `ocaml-solo5` was done and a pending PR exists about `mirage-xen` to be able to get these informations: https://github.com/mirage/mirage-xen/pull/48
All of that is related to some issues found about `qubes-firewall` and Solo5, you can see the CHANGES.md of Solo5 here: https://github.com/Solo5/solo5/pull/518
Waiting to merge the reproducible build PR on MirageOS 4 and be able to:
1) do a release of `mirage-xen` (which includes allocation metrics)
2) do a release of `mirage` with right bounds about `mirage-xen`/`ocaml-solo5` (because the API was updated)

This release will be done probably in a few weeks.

## Job rounds

### Pierre round

pierre: question about memory consumption and mirage-xen PR (https://github.com/mirage/mirage-xen/pull/48) should we merge what we did on `mirage-xen` into `mirage-solo5` (because they use the same things, eg. solo5)
romain: for me it's good to do
pierre:I did an unikernel which implements a NAT router into the Tor network, https://github.com/palainp/torrefacteur
thomas: it's like an unix gateway?
pierre: I would like to replace the unix gateway by a VM, so yes be able to route some traffic on default gateway and route some traffic on tor
thomas: will be a useful unikernel
reynir: Hannes made a PR (https://github.com/mirage/ocaml-conduit/pull/414) into conduit which should fix the issue about the Tor unikernel
pierre: I saw the fix but I'm not sure how to use this fix. I think I need to work on something on what Hannes wrote on this PR
pierre: I also have a question. I wrote a code to work with ESP32 to be able to use it as a wifi card with the PPP protocol. Then, I can use this controller to process the wifi. I have a question about Gilbraltar (RPi4) which does not yet have a network. PPP interesting?
timada: if you want to use TCP/IP with MirageOS on a micro-controller, you need to have both a TCP/IP handling layer on MirageOS and also basically a packet transmitting/receiving layer which is provided on the C layer. For instance, the packet transmitting/receiving layer is implemented by the Linux operating system for unix, seccomp. For a microcontroller, you must have something which handles that.
romain: for RPi4, the difficulty is about the Ethernet driver which is missing from Gilbraltar. But if someone wants to implement the Ethernet driver, it's just a matter of plugging `mirage-tcpip` then and you have a full network stack. More concretely, you need to deal with *mbox* and interrupts to be able to implement the ethernet driver, a PR exists on Gilbraltar which handles interrupts from the CPU to the OCaml side (https://github.com/dinosaure/gilbraltar/pull/19). From it, you should be able to implement an Ethernet driver in OCaml may be (with few C codes)
timada: https://mcuxpresso.nxp.com/api_doc/dev/329/group__lpc__enet.html this is an ethernet driver target to bare-metal and it does not depends to highly complexe Linux things, it can be interesting. I think it's difficult to port the ethernet driver from Linux to bare-metal.
romain: Yeah. the ethernet driver for RPi4 provided by Linux is too complex for us and require too many things but I found a bare-metal ethernet driver too in C++ (https://github.com/rsta2/circle/blob/master/lib/bcm54213.cpp) (BCM54213PE PHY). From a quick look, it should not be super difficult to implement it.
timada: if we use a small microcontroller, in many cases the microcontroller provides something for ethernet/wifi. And you probably can use them. Like ESP32 provides that.

### Romain

romain: try to implement a peer-to-peer file-transfer with a simple tool and a unikernel as a relay. Implement the protocol with SPAKE2+EE (https://github.com/dinosaure/spoke) and the tool (https://github.com/dinosaure/bob)

# Thomas

thomas: Look into the eio supports on MirageOS 4, I would like to upgrade mirage-skeleton with eio. Be able to use the direct-style on some of them.

# Reynir

reynir: Caldav code, otherwise I work on builder/reproducible build
romain: maybe you can talk about caldav
reynir: It's an unikernel which implements a CalDAV server with the CalDAV protocol. Git is used as the store. You can create users and multiple calendars.
romain: we currently use it (4 peoples) to find some bugs by usage and improve it.

# Timada

timada: Solo5 on microcontrollers, I also need to understand the muen Solo5. Especially the muen framework. The new building framework is different from the previous one. Look into `ocaml-solo5`, `solo5`
romain: yeah the new layout of Solo5 is about _toolchains_. Solo5 provides a new toolchain (like `cc`, `ld` and `objcopy`) which is a wrapper with a compiler (like `gcc` or `clang`) or a cross-compiler (like `aarch64-gcc`). Then, `ocaml-solo5` uses this C toolchain to compile the _caml runtime_ and provide a new OCaml _toolchain_. At the end, for the mirage tool and depending on what the user wants, we choose the right OCaml _toolchain_.
timada: What about `opam monorepo`?
romain: Yeah, it's mostly about (transitive?) dependencies which include C stubs. We must compile them with certain flags (like `-ffreestanding` or `-nostdlib`). These flags will be provided by the OCaml toolchain which use the correct C toolchain (the `cc`/`ld`/`objcopy` provided by Solo5 first). By this way, we compile everything needed by the unikernel into a coherent `dune`'s context.
timada: I'm currently testing my test compilation with a very simple Makefile. It does not care about `opam-monorepo`. I will look into that.

Re: no meeting today; but in two weeks