Now: Understanding Muen and base_hw kernel from docs, [Earlier] Re: Problem with make run/demo ....

[Norman Feske]

Hello Shahbaz,

>     I've been wondering, is there any reason not to use
>     base-hw_x86_64_muen on regular hardware? It seems to work fine in
>     Qemu, and 
> 
> 
> Release notes mention Thinkpad X201.Muen website makes me cautious but
> if Qemu works then we are good for a start. Have your tried virtualbox?

Muen relies on hardware-assisted virtualization (Intel-VT). For running
it inside a virtual machine, the virtual machine must support nested
virtualization. As far as I known, VirtualBox does not support that.

> Well anything is easily possible with micro-kernel architecture in
> concept but I was curious whether we run base_hw kernel that is muen
> according to mainline repo's files.

Let me try to clarify the roles of Muen, base-hw, and VirtualBox:

* Muen is a static separation kernel that uses VT to turn one physical
  machine into a statically configured number of "partitions" (aka
  "subjects"). Each partition is similar to a virtual machine. So
  partitions are rather coarse-grained and static. Muen runs in
  VT-root mode whereas the partitions run on VT-non-root mode.

* Base-HW is a microkernel that uses virtual memory (like page tables)
  to establish the notion of sandboxed user-level components on top
  of it. Those components are light-weight and dynamic. To draw an
  analogy, if you imaging a Muen subject to be a virtual machine, you
  may think of a Genode component as an OS process. The base-hw kernel
  runs in kernel mode whereas the components run in user mode.

* VirtualBox is both a low-level piece of software that closely
  interacts with virtualization hardware, but also a sophisticated
  user-level application that relies on broad higher-level OS
  infrastructure. E.g., it expects the underlying operating system
  to provide host device drivers (for graphics, networking, input,
  audio, block devices, USB), it needs to accesses virtual disk images
  via an OS-provided file system, it spawns multiple threads, etc.

The role of Genode (including base-hw) in this scenario is to bridge the
gap between the rather spartan environment of a Muen subject and the
high functional requirements of the VirtualBox application. So you may
see Genode as a mere runtime environment for VirtualBox. In principle,
this gap could be filled by another software stack like a Linux-based
OS. But as I stated above, in addition to being a complex application,
VirtualBox closely interacts with the virtualization hardware. On Muen,
this interaction naturally has to go through the Muen SK. By using
Genode as runtime for VirtualBox, Muen is able to leverage Genode's
existing solution of the interaction of VirtualBox with a
microkernel-based virtualization mechanism.

>         I got a bit acquainted with the release notes but I still find
>         it difficult to comprehend what really base-hw means when we say
>         "Genode base -hw" on Muen SK.

Conceptually, a Muen partition is a hardware platform, similar to a
board. Like on any board, you can run software directly (in supervisor
mode). But for running a complex software stack, or more than one
application, one has to use an operating system (OS). Genode/base-hw
plays this role.

>         I am having some build issues (I do get an image.elf but build
>         does not complete) and have yet not looked into earlier commits
>         and branches so I would appreciate if you can let me know what
>         actually runs over Muen SK in Genode base-hw kernel VM. Does it
>         mean we run another kernel like nova between Muen and virtualbox.

Base-HW is unrelated to NOVA or any of the other kernels. It is a
microkernel specifically developed for and tightly integrated with
Genode. Think of it as an optional back end of Genode to run
Genode-based systems directly on hardware (or virtual hardware like a
Muen partition) without a third-party kernel.

Regards
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth