Adrian-Ken Rueegsegger e3fbeeb25e vbox: Implement hwaccl support for Muen
* Implement VMMR0_DO_VMMR0_INIT operation for Muen

   - Indicate VT-x support
   - Enable unrestricted guest mode
   - Set CR[0|4] mask to enable masking of guest CR0.[NE,NW,CD] and
     CR4.VMXE bits.

 * Implement VMMR0_DO_GVMM_CREATE_VM on Muen

   Return error if trying to create SMP VM as VMs with multiple CPUs are
   currently not supported on hw_x86_64_muen.

 * Add Muen-specific Mem_region type

   On hw_x86_64_muen the guest memory layout is static, thus regions are
   handed out from an array of memory regions.

   Use sinfo API to calculate the base address of the VM RAM physical
   0x0 region. This allows to dynamically modify the VM RAM size by
   adjusting the Muen policy and Genode vbox files accordingly.

   Zeroize all memory regions apart from VM Ram since Virtualbox expects
   these regions to be cleared.

 * Add Muen subject state struct

   The subject state encompasses the guest VM machine state that is
   transfered between Virtualbox and hardware accelerated execution on
   Muen.

 * Add Muen-specific Vm_handler class
 * Use Vm_handler to run VM
 * Instruct recompiler to flush its code cache
 * Copy the Muen subject state to/from the Vbox PCPUMCTX.
 * Use the VM interruptibility state to inform the recompiler whether
   interrupts are currently inhibited.
 * Explicitly handle control register access

   If a VM-exit occurs due to a control register access, handle it and
   directly continue hardware accelerated execution of guest VM.

   Note: On NOVA control register accesses are handled by the kernel [1].

   [1] - https://github.com/alex-ab/NOVA/blob/master/src/ec_vmx.cpp#L106

 * Reset guest interruptibility state

   Assert that interrupts are not inhibited in the Virtualbox machine
   state and clear Blocking-by-[STI|MOV to SS] guest interruptibility
   flags prior to running a guest VM in hwaccel mode.

 * Set return code depending on exit reason

   Do not unconditionally emulate the next instruction on VM exit. This
   makes sharing the VM FPU state with Virtualbox unnecessary, as FPU
   instructions are not emulated by the recompiler any longer.
   Also, assert that the FPU has not been used by the recompiler

 * Inject pending guest VM interrupts on Muen

   Use mapped subject pending interrupts page of guest VM to perform
   interrupt injection. IRQs are transferred from the Virtualbox trap
   manager state to the pending interrupts region for injection. If an
   IRQ remains pending upon returning to the recompiler, it is copied
   back to the trap manager state and cleared in the subject interrupts
   region.

 * Inform recompiler about changed SYSENTER_[CS|EIP|ESP] values,
   otherwise values set while running the guest VM hardware accelerated
   may get lost.

 * Implement genode_cpu_hz() on Muen

   Determine the CPU frequency dynamically using the sinfo API.

Issue #2016
2016-07-06 13:02:56 +02:00
2016-07-06 13:02:54 +02:00
2016-05-26 15:54:16 +02:00
2015-05-06 10:55:23 +02:00
2011-12-22 16:19:25 +01:00
2016-05-26 15:54:17 +02:00
2016-05-27 11:36:56 +02:00

                      =================================
                      Genode Operating System Framework
                      =================================


This is the source tree of the reference implementation of the Genode OS
architecture. For a general overview about the architecture, please refer to
the project's official website:

:Official project website for the Genode OS Framework:

  [https://genode.org/documentation/general-overview]

The current implementation can be compiled for 8 different kernels: Linux,
L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
kernel for running Genode directly on ARM-based hardware. Whereas the Linux
version serves us as development vehicle and enables us to rapidly develop the
generic parts of the system, the actual target platforms of the framework are
microkernels. There is no "perfect" microkernel - and neither should there be
one. If a microkernel pretended to be fit for all use cases, it wouldn't be
"micro". Hence, all microkernels differ in terms of their respective features,
complexity, and supported hardware architectures.

Genode allows the use of each of the kernels listed above with a rich set of
device drivers, protocol stacks, libraries, and applications in a uniform way.
For developers, the framework provides an easy way to target multiple different
kernels instead of tying the development to a particular kernel technology. For
kernel developers, Genode contributes advanced workloads, stress-testing their
kernel, and enabling a variety of application use cases that would not be
possible otherwise. For users and system integrators, it enables the choice of
the kernel that fits best with the requirements at hand for the particular
usage scenario.


Directory overview
##################

The source tree is composed of the following subdirectories:

:'doc':

  This directory contains general documentation. Please consider the following
  document for a quick guide to get started with the framework:

  ! doc/getting_started.txt

  If you are curious about the ready-to-use components that come with the
  framework, please review the components overview:

  ! doc/components.txt

:'repos':

  This directory contains the so-called source-code repositories of Genode.
  Please refer to the README file in the 'repos' directory to learn more
  about the roles of the individual repositories.

:'tool':

  Source-code management tools and scripts. Please refer to the README file
  contained in the directory.


Contact
#######

The best way to get in touch with Genode developers and users is the project's
mailing list. Please feel welcome to join in!

:Genode Mailing Lists:

  [https://genode.org/community/mailing-lists]

Languages
C++ 73.8%
C 17.9%
Makefile 4.4%
Tcl 1.3%
PHP 1%
Other 1.4%