Thank you for your detailed and caring reply. I believe i got lost with the build think diagram. The diagram is not purely a runtime diagram.
On Saturday, April 15, 2017, Norman Feske <norman.feske@...1...> wrote:
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.
Good to know in time.
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.
Similar to karma-vmm, fiasco.oc and l4linux.
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.
Simply put a build time think. Base-hw kernel means muen sk for genode runtime.
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.
By the way it seems fiasco.oc is not being maintained. Is something better available, which supports both micrkernel based runtime and virtualization..?
Regards, Shahbaz