Re: MirageOS biweekly meeting; next Mar 15 2023 14:00 CET

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hey,

our notes are below -- next meeting in two weeks (Mar 15th 14:00 CET in 
whereby.com/ocamllabs), agenda 
https://pad.data.coop/k2z2UqDCQ1G1ZOic6g7XwA# (please add stuff you'd 
like to discuss).
Best,

Hannes

# MirageOS meeting 2023-03-01

Attendees: reynir, Pierre, Taka, Lortex, Thomas Leonard, Hannes, dinosaure

## Clock drift in solo5 (reynir)
- https://github.com/Solo5/solo5/issues/549
- on suspend and resume, the hvt clock gets behind several weeks
- solo5 takes the offset once and uses that to compute the wall clock time
- ways forward:
  - use the system call on every `now_d_ps ()` call (will be slow)
  - keep the offset, but recompute every few minutes (according to 
monotonic clock)
  - provide access to the system call/hypercall (would require changes 
to mirage-clock code)
- curious how a NTP implementation could work (since we don't get any 
notification from the OS when the computer goes to sleep / resumes)
- reynir also suggests to move the offset computation into the mirage code

## Solving recent breakages in MirageOS 4 (Lortex)
- recent changes to the opam-repository lead to mirage failures:
- dune 3.7 changed semantics that broke chamelon package (which 
opam-monorepo always picks the latest release of dune)
- ppxlib 0.29 included a vendoring of ppx_sexp_conv, which lead 
opam-monorepo to provide multiple ppx_sexp_conv
- dune 3.7 uses `(lang dune 3.5)` and opam-monorepo pulls in the latest 
dune - which then can't be built if the switch has dune<3.5.0.
### solution: custom opam repository for MirageOS unikernels
- a solution would be to maintain a custom opam-repository at the mirage 
organization that is automatically updated (& merged) when the mirage CI 
succeeds
- we could even provide a branch of that opam-repository for each mirage 
minor release to sustain working versions, and drop upper bound 
constraints from the mirage utility
- instead of adding dune-overlays etc. in the Makefile (during 
depend/pull), add the mirage-opam-repository
- action item 1: extend the Mirage CI to run on that repository
- action item 2: extend the Mirage CI to update the 
mirage-opam-repository when opam-repository or dune-overlays repository 
updates
- action item 3: send notifications to opam-repository PRs

## mirage configure should check whether config.ml is compatible with 
the mirage version
- https://github.com/mirage/mirage/issues/1381
- maybe a step before mirage configure is executed is needed (comparing 
the output of --version with the required minimal (maximal?) one)
## Solo5 and OCaml 5 (thread local storage -- Pierre)
- https://github.com/Solo5/solo5/pull/546
- Pierre did some work on how solo5 could deal with thread specific 
variables (`__thread`) that OCaml 5 runtime adds
- it is difficult: two toolchains (gcc & GNU ld vs clang & lld)
- Pierre has developed linker scripts that work for both GNU ld and lld
- at the moment, 4kB are reserved for the TLS
- the PR exposes the size of tbss and tdata segments so ocaml-solo5 can 
allocate that region
- the linker computes the size/offset of the section
- review of that PR is highly welcome
- in the future (multiple CPUs), we'll need to allocate one tdata+tbss 
per CPU and copy over the tdata
- unclear whether it works on powerpc or arm64
- tested on OpenBSD & Linux tested on X86
- action item 1: review PR
- action item 2: test on powerpc & arm64

## Old issue in qubes-mirage-firewall (Pierre)
- https://github.com/mirage/qubes-mirage-firewall/issues/107
- sys-net is not autostarted, q-m-f receives a EACCESS
- proposal: wait for xenstore being initialized with the network interface
- (possible?) fix in 
https://github.com/palainp/mirage-net-xen/commit/1afc600c96dd8c6b6024d383de0dae21cf9151c7
- On Qubes-os forum: 
https://forum.qubes-os.org/t/libxenlight-failed-unable-to-add-vif-devices/16958/1
- action: wait for qubes forum user to test whether the above commit 
fixes their issue
## next meeting March 15th 14:00 CET https://whereby.com/ocamllabs