Xen project Mailing List

As before, this is what we talked at the meeting (the source comes from: https://pad.data.coop/wGS4r8RyTKqQ73mcw7FrwA?both)

# MirageOS community call

### 26/02/2024

- Present: dinosaure, Pierre, Hannes, Virgile, Thomas G. Thomas L., Samuel, Shakthi, Magnus
- Agenda:
- Meta:
- Should we use Zoom or something else?
- Pierre: Some universities cannot use Zoom on Linux.
- Dinosaure: Prefers to use Jitsi.
- Virgile: Can use Renater (which uses Jitsi) if someone has a renater account.
- Pierre-Alain will investigate.
- Hannes: there is the public instance jit.si where no registration is necessary (as used e.g. in the opam-repository meetings)
- Should we use https://pad.data.coop/ or something else? => Pad seems good!
- Anyone willing to help organising these calls? (send , taking notes, etc.)
- Next meeting will be organised by Magnus :-) Thanks (and Virgile is also happy to help)
- MirageOS retreat update?
- 16 people signed up! early-birds registration seems to work fine
- still space available - even for a few days and/or for the week-end
- mix of people that have been there before, and new people!
- PR updates
- solo5+ocaml5: https://github.com/mirage/ocaml-solo5/pull/124
- Samuel and Fabrice are trying to revive the PR. Cleaning up the x-compiler story for the OCaml compiler in a state that could be upstream. The goal is to clean up all the pieces are glued together. Still trying to understand how the various details are working (like memory allocation). Target: OCaml 5.2 (which include compaction) as many things have changed.
- Hannes: there are 2 or 3 PRs that pretend to do something with OCaml 5. Some of them have a lots of comments from Christiano and others. Is there a plan to merge/review those comments too? Some stuff implemented in C were a bit brittle. Would be sad if we lose these reviews.
- Samuel: plan is probably to open a new PR that adress all of the comments (#122, #124, #129). Many things have changed in 5.2.
- Dinosaure: what's the issue with x-compilation? Samuel: many ways in the way ocaml-solo5 works is to patch the OCaml build system (with a few things broken as a result). Things are very brittle. We would like to have something more solid. Dinosaure: this seems independant? Could we decouple those concerns? Samuel: indeed. currently trying to understand how things work but the idea is to reduce the maintenance as well. and to understand what is needed for solo5 vs. x-compilation. Dinosaure: see ocaml-solo5#123 (most issues are related `configure`). Samuel: will talk to Sebastien next
- mirage runtime keys v2: https://github.com/mirage/mirage/pull/1493
- Thomas:
- use cmdliner directly, instead of a custom fork
- keys are split into configuration time keys and runtime keys
- the runtime ones are only defined at runtime
- it is a breaking big change
- Hannes:
- configure-time: you select what libraries you want to use in the unikernel (keys)
- runtime-time: you select some runtime parameters (ip address, etc.)
- better type for key
- issue: type errors, locations in generated code
- Happy with the current state but do not have time to review fully
- Thomas:
- updated existing unikernels
- worked on error locations (you need to pass `__LOC__`)
- there's a OCaml compiler patch that does this automatically
- ~all examples and documentation will need to be updated to reflect the new interface: big workload
- Hannes: can we remove the dependency between mirage and mirage-runtime
- Dinosaure: the idea looks good, and the possibility to add custom types (via cmdliner) is nice
- Thomas: will make progress for the next call
- MirageOS relies on "opam-monorepo", what is the schedule switching to "dune pkg" (last was "Q1/2024" - anyone actively working on that)?
- the dune and opam team worked for the last year to include opam-lib into dune
- dune will be able to compute (make a lock file), download packages it needs locally, and compile each opam package (even if the package is not using dune)
- single tool to define dependencies, whenever you modify the dune file, the opam packages are updated
- rules will be cached
- it is similar to opam-monorepo
- packages need to be relocatable (not all are, e.g. the compiler)
- there'll be a small overlay (similar to opam-monorepo overlay) for a small set of packages that are not possible to build with "dune pkg"
- timeline: first alpha was planned end of Q1, now scheduled for May
- what needs to be done for mirage? we haven't tested it yet. need to discuss and test once an alpha is around (thomas will test even earlier)
- for now we need to keep opam-monorepo
- Thomas: are there urgent pains to address?
- Hannes: hard to use old versions of dunes, ...
- Hannes: Is there any specification of how dune pkg will download/organize etc., for the purpose of reproducible builds? -- Thomas: it created a lock file and downloads using opam-lib
- Hannes: carton/git issue with opam-monorepo -- Thomas: this will be fixed in "dune pkg"
- Dune pkg milestone: https://github.com/ocaml/dune/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Package+Management+MVP%22
- dune+orb (reproducible build integration): https://github.com/ocaml/dune/issues/9548
- Performance considerations for MirageOS (let's take mirage-crypto as example)
- EC NIST curves pre-computed tables -- https://github.com/mirage/mirage-crypto/pull/191 shows a speedup of 4x
- mirage-crypto symmetric cipher (AES-GCM / Poly1305-Chacha20) around 10x slower than OpenSSL (see https://github.com/mirage/mirage-crypto/pull/203, a speedup of ~2.5x for chacha using string/bytes)
- cstruct.t vs bytes -- https://blog.robur.coop/articles/speeding-ec-string.html shows a speedup of 2.5x
- or replace the underlying structure of cstruct from bigarrays to bytes? "Just" have to take care of IO-pages which still need aligned addresses
- for Xen interfaces we need page-aligned non-moving memory areas
- Dinosaure: don't use _systematically_ Cstruct‧t and probably we should use bytes more systematically and asking ourselves about particularities of bigarray
- Thomas: Patrick has started a Bstruct library: https://github.com/ocaml-multicore/ocaml-uring/pull/101
- mirage-flow + shutdown (https://github.com/mirage/mirage-flow/pull/48)
- Hannes: released to opam-repository as mirage-flow 4.x
- Hannes: anyone eager to review: https://github.com/mirage/mirage-tcpip/pull/512
- Thomas: will ping Dave
- Next meeting - https://meet.jit.si/mirageos-call, 9 CET in two weeks (March 11th)

### Moved to next meeting
- Unikraft+mirage plans
- How can we improve the security story around MirageOS? What are the security issues with mirage?
- What do we want Mirage5 to look like?
- Ocaml 5 support
- No more Lwt?
- IncludeOS / Mirage

As decided, the next meeting will be on March 11th (9 CET). We decided to use Jitsi now (instead of Zoom): https://meet.jit.si/mirageos-call

Thanks for your participation.

Re: MirageOS meeting 2024-02-26 - 9:00 CEST