Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.
Adam Wick edited this page Dec 4, 2016 · 19 revisions

The Haskell Lightweight Virtual Machine (or, informally, the HaLVM) is a port of the GHC runtime system for Haskell to barebones Xen. This means that Haskell programs written for the HaLVM run natively on Xen, without any intervening operating system, which allows them to boot quickly and use very little space.

The HaLVM is released under a non-restrictive BSD3 license. If you are using the HaLVM for something in your work, please email us at halvm@galois.com! We would very much love to hear about it.

Current Release

The current "release" is a Developer's Preview of HaLVM Version 2.0. HaLVM 2.0 brings ...

  • An update to GHC 7.8
  • Support for GHC's threaded runtime, which appears to dramatically improve performance.
  • SMP HaLVM support
  • 0-copy networking (sort of)
  • Much more sensible base library APIs
  • Improved compatibility with existing libraries.
  • Profiling Support

This is a preview release: please do not use this for critical systems.

Why did you build the HaLVM?

Galois began development of this technology in 2006, as a mechanism by which to prototype basic operating system structures and test their behavior. Since that time, we have used it internally in several different projects to explore interesting design spaces in that area. Because HaLVMs run directly on Xen, there is no artificial kernel-land / user-land barrier imposed by an intervening OS when writing very low-level code. On the other hand, because Haskell is such a high-level language, refactoring multiple components into a single component (or ''vice versa''!) is simple and easy.

How to I get the HaLVM?

For those using Fedora, the easiest way to get started with the HaLVM is to add the official HaLVM repository to your yum configuration and download the pre-built Xen and HaLVM sources. If you are viewing this wiki page on your development machine, you should be able to click here for Fedora 24 or click here for Fedora 25. Otherwise, you can download and install the package from the command line, as follows:

For Fedora 24:

 dnf install http://repos.halvm.org/fedora-24/x86_64/halvm-yum-repo-24-3.fc24.noarch.rpm

For Fedora 25:

 dnf install http://repos.halvm.org/fedora-25/x86_64/halvm-yum-repo-25-3.fc25.noarch.rpm    

Then run dnf update and dnf install halvm-xen halvm-xen-devel HaLVM. After installing these packages, reboot Fedora using the Xen Hypervisor option in the bootloader.

We are working on similar pre-built binaries for Debian.

Alternatively, please see the README file associated with the HaLVM for building the HaLVM from scratch. You can see it (and the HaLVM repository) by going to the GitHub main page.

Please consider signing up on the halvm-devel mailing list.

What do I do with it? What can I do with it?

Whatever you want, really. We started out using it as a platform for playing around with operating system design, and then later started thinking about how to use it for network services. Perhaps you want to write a cool network appliance for your company. Perhaps a tiny random number server for your company? Perhaps an interesting and complicated web service? Possibly even a little interpreter for doing cool things. All these are possible, and more.

The HaLVM comes with an array of examples and test cases, located in the examples directory of the main HaLVM tree. These may be a good place to start (you may need to install the package openssl-static to compile all of the examples). In addition, we recommend checking out the library documentation for the HaLVM-specific libraries.

Finally, we strongly recommend you at least flip on the verbose option for your hypervisor, as described in the section SupportedSystems. This makes debugging much easier.

How can I get involved?

We are always looking for ways to improve the HaLVM, either through new features or bug fixes. If you would like to get involved, feel free to grab your own fork of the HaLVM and get going! We are always looking for new developers interested in pushing the state of the HaLVM. In general, we're very open regarding new features or bug fixes, however please follow these simple guidelines:

  • Do not use tab characters unless you are forced to by the file format.
  • Please keep your line lengths to 80 characters or less.
  • We'd greatly appreciate it if you tried your patch from a clean build (a fresh checkout of your fork) before sending it to us.

How do I develop HaLVMs?

The HaLVM is a nifty tool, but there are some down-sides. One critical downside is the lack of debugging tools, which can make finding and fixing errors a bit more difficult that usual. So if you want to write HaLVM code, here are a few suggestions to help you along:

  • First, try to write as much code as you can as a normal Haskell program. This will make your life a lot easier while you're developing the majority of your code. Many of the higher-level libraries that make the HaLVM a bit more pleasant to work with (Hans, Halfs, etc.) have normal-world variations that you can use for testing. Once you're done with this conversion, then work on refactoring your system so that you can have both normal-world and HaLVM variants. Only at that point should you start putting things on the HaLVM.
  • Second, the debugging mechanisms in the HaLVM are limited to three basic mechanisms, as follows:
    • writeConsole: Using the normal Xen console to determine input values. This can work in some cases, but beware: this console is heavily buffered. Thus, it can be useful for printing input values but has less use as a "did I get here?" debugging aid.
    • writeDebugConsole: The Xen debug console can contain more information about your problems than the normal console. To make use of it, you must have used a custom Xen build that set "verbose=y" in the build process (versions of these packages for Fedora 19 can be found here). The Haskell function writeDebugConsole will send output to this console, as will printf from C. To see the output, run "xm dmesg" from the Dom0 command line.
    • Divide by 0. If the HaLVM experiences a division by 0 fault, it will print information to the debug console (see previous). This is a last-ditch way to tell if you've gotten to a particular location, if (for some reason) you're worried about print not working.

If you are planning to work on the HaLVM itself, rather than building HaLVMs, the above tips still apply. In addition, be aware that the current build system is flaky. There's a ticket on this subject. Because of its various oddities, it will sometimes fail to build modified files, and will sometimes fail to build dependencies it should. So if you're debugging a problem and what you're seeing seems crazy, consider 'make clean'. And if that doesn't help, consider pulling a fresh version of the repo and starting from there. Apologies for the inconvenience: it's on our list. In addition, if this seems like a problem you'd like to tackle, please comment on the ticket and see what you can do!

What to know more?

See useful links