Changes between Version 9 and Version 10 of Developer/Projects/Open/Paravirtualization


Ignore:
Timestamp:
02/13/12 04:36:58 (12 years ago)
Author:
Gedare
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Developer/Projects/Open/Paravirtualization

    v9 v10  
    1717
    1818'''Resources:''' Existing partitioning/isolation layer, such as POK (see http://pok.safety-critical.net) or AIR (http://air.di.fc.ul.pt/)
     19= Summary =
    1920
    20 
     21Some projects provide software to isolate different RTEMS instance in a virtual machine (for example, Xtratum), and each need to tailor RTEMS for their own needs and adapt it to communicate with the hypervisor. Tailoring RTEMS for each hypervisor can be hard, especially since these solutions do not share/commit back their efforts; instead we want to define a generic adaptation layer that [http://en.wikipedia.org/wiki/Paravirtualization paravirtualizes] RTEMS to ease the tailoring of RTEMS to run as a guest in a virtual machine. This project can proceed in two phases: one to design an adaptation layer for RTEMS paravirtualization and another to implement the interface for a particular hypervisor to execute RTEMS instances. For the second phase an open-source hypervisor should be used.
    2122= Proposed Approach =
    2223
    2324
    24 The project could be separated in two different efforts : define an API in RTEMS to execute privileged instructions and adapt an existing partitioning kernel to execute RTEMS instance.
    25 = Adapt RTEMS for privileged instructions =
     25The project has two phases: paravirtualize RTEMS and adapt an existing partitioning kernel to execute RTEMS as a paravirtualized guest.
     26= Paravirtualize RTEMS =
     27
     28== Privileged instructions ==
    2629
    2730This consists in reviewing RTEMS code and identifying which part of the code requires privileged instructions. After these code review efforts, the goal of this first activity would be used to design an architecture-agnostic API to execute privileged instructions. Basically privileged instructions would be wrapped so that when RTEMS is running as a guest OS it will instead make hypercalls to the hypervisor layer.
    2831
    29 Finally, the last part of this effort would consist in implementing the API for one or two architectures (initially x86 and SPARC are good targets) and lay the road map for more ports.
     32The API should be implemented for one or two architectures (initially x86 and SPARC are good targets) and lay the road map for more ports.
    3033
    3134For that, the project could reuse the results of the previous Google Summer of Code project (in 2011) (see [wiki:GSoC/2011 RTEMSSummerOfCode2011])
     35== Devices and I/O ==
     36
     37'add details'
    3238= Adapt existing isolation layer =
    3339
    34 Second step of this project is to adapt an existing partitioning kernel/isolation layer to execute RTEMS instances. Ideally, this would be implemented in an existing FOSS isolation layer. Actually, two FOSS projects provide such functionalities : Air and POK. Ideally, developers may evaluate the feasibility on each isolation kernel and choose the most appropriate solution.
     40Second step of this project is to adapt an existing partitioning kernel/isolation layer to execute RTEMS instances. Ideally, this would be implemented in an existing FOSS isolation layer. Actually, two FOSS projects provide such functionalities: Air and POK. Ideally, developers may evaluate the feasibility on each isolation kernel and choose the most appropriate solution.
    3541= References =
    3642