Skip to content

[RFC] rump hypcall integration for LKL#255

Open
thehajime wants to merge 11 commits into
lkl:masterfrom
libos-nuse:rump-hypcall-upstream
Open

[RFC] rump hypcall integration for LKL#255
thehajime wants to merge 11 commits into
lkl:masterfrom
libos-nuse:rump-hypcall-upstream

Conversation

@thehajime

@thehajime thehajime commented Oct 28, 2016

Copy link
Copy Markdown
Member

(since this is RFC, I'd be happy to have any comments and suggestions from yours)

This PR provides an initial implementation of rump kernel hypercalls (*1) which brings us a couple of interesting features to LKL.

The highlight of new features are:

  • additional host environments, NetBSD, qemu-arm, qemu-x86_64, xen other than linux/freebsd/windows which current LKL supports.
    • execuse: I haven't tested that much, only tested with qemu-arm, qemu-x86_64 on Linux.
  • non hijack-based existing application support with a dedicated libc bind to LKL using musl libc
    • rumprun/frankenlibc unikernel integration
  • new thread primitive based on green thread (a.k.a. userspace thread, related to official usermode thread support in LKL #250 ?)

The addition of rump hypercalls does not interfere the current implementation of LKL, but with additional external repositories (*2), you will run LKLed applications with rump hypercall.

Non-hijack application support requires to build an (existing) application by dedicated build toolchain (cross compilation as rumprun does), but it will solve most of hijack limitations such as conflicted symbols/namespaces, non exposed symbols (e.g., replace hidden symbols in glibc). With this toolchain, I confirmed nginx, netperf, and ghc (a haskell compiler) somehow work fine, though those need more work to be more than just a hello world.

The green thread implementation is obviously useful to avoid the expensive task of context switches. I saw some of netperf benchmarks outperform pthread based one (will re-measure with netperf in my spare time).
(rump hypercall has pthread-based thread implementation but I didn't test it in this PR).

I'm going to upstream the external repositories (*2) as well as this PR so, this PR will be a base of all of external dependencies.

I think merging non-master branch of LKL and synchronize periodically with master branch is also reasonable since the changes (of this PR) are a bit large.

*1 rump kernel
http://book.rumpkernel.org

*2 additional (external) repositories


This change is Reviewable

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants