Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove specialization of hvt tender at unikernel compile time #326

mato opened this Issue Feb 20, 2019 · 3 comments


None yet
1 participant
Copy link

mato commented Feb 20, 2019

A long-standing design issue in Solo5 is the specialization of the hvt tender being done at unikernel compile time, which is a hold-over from the days of ukvm.

With the introduction of the spt tender the problem has become even more pronounced, so the time has come to remove this concept from the codebase.

Among other things (see linked mailing list post for more), this change is blocking:

  • A sane supply chain, allowing the operator (not the developer) to supply the solo5-hvt tender. This is a pre-requisite for a better deployment story, e.g. integration with libvirt-based systems for deployment.
  • Sharing code between the hvt and spt tenders (e.g. ELF loader, common host device/module setup code).
  • Support for multiple instances of block/network devices, and support for "future" devices (e.g. host-only communication channels).

The following sub-tasks are part of this work:

  1. Remove compile-time specialization with minimal changes to the current codebase.
  2. Solo5 API changes required to support this change.


  1. As a start, we will build one solo5-hvt tender with all non-debug modules present. the tender will allow any combination of devices to be enabled at run time, i.e. post this step it will no longer enforce any contract between the unikernel and its host on what resources (network, block devices) are required by the unikernel to run.
  2. The Solo5 API needs to be able to report that a device is invalid rather than just assert() internally. As part of this change, preparatory work will be done to allow for the existence of multiple devices, though initially there will still be only one hard-coded {net, block} device supported.

After this is complete I will raise a separate issue to deal with the actual implementation of multiple device support and adding back the enforcement of the host/unikernel contract by the tender as the two are ultimately intertwined.

@mato mato added the target/hvt label Feb 20, 2019

@mato mato self-assigned this Feb 20, 2019

@mato mato added the api change label Feb 20, 2019


This comment has been minimized.

Copy link
Member Author

mato commented Mar 5, 2019

Progress update: Working on this has led to an overdue refactoring of the build system, with the following overall goals:

  1. Correct dependency handing. i.e. make must always rebuild what has changed, with a minimal amount of dependencies specified manually in Makefiles.
  2. Clear data flow throughout the build system. The build system needs to produce four groups of artifacts (bindings for A targets, B tenders for the host, C tests for A targets and D .pc files for use by OPAM), using different compilers (or flags). As things currently stand, the number of combinations leads to unmaintainable spaghetti code.
  3. Removing as much repetition as possible, without going too deep into GNU make "magic" (limiting use of macros and $$$$(FOO) unless absolutely necessary). Otherwise use best practices where possible.
  4. Allow for sharing of common code between tenders.

Unfortunately there are far too many ways to shoot oneself in the foot with GNU make, so this will take some time to stabilise.

For those that want to follow along, my work in progress branch is at This is not yet functional with OPAM/MirageOS.


This comment has been minimized.

Copy link
Member Author

mato commented Mar 15, 2019

Progress update: The last week or so has been spent writing an end to end smoketest for Mirage/Solo5, and learning a lot of OCaml along the way! The E2E test is needed in order for me to be able to reproducibly test Solo5 API and build system changes against downstream Mirage/Solo5 using a single command (i.e. score the "Can you make an (end to end) build in one step?" on the Joel Test).

The E2E code temporarily lives at, and will likely move into the Solo5 repository under tests/ for practical reasons once I'm happy with it.


This comment has been minimized.

Copy link
Member Author

mato commented Mar 22, 2019

Progress update: The E2E tests have been merged in #340. Next up will be a PR with the build system refactor and removal of compile-time hvt specialization (step 1 here).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.