Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Version 46 and Version 47 of GSoC/2013/ParavirtualizationOfRTEMS


Ignore:
Timestamp:
09/19/13 18:15:07 (11 years ago)
Author:
Phipse
Comment:

HowTo? section with architecture and hypervisor port howto

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2013/ParavirtualizationOfRTEMS

    v46 v47  
    448448Claudio da Silva has provided one [https://gist.github.com/cdcs/5874932 here].
    449449
    450 =  More Hypervisors (L4Re) =
     450=  More Hypervisors (L4Re)  =
    451451
    452452
     
    466466So it doesn't need to be present at compile time.
    467467Furthermore, it we should be able to reuse the virtualpok BSP, provided we replace libpart.a with a library provided by L4Re.
    468 
     468=  HowTo  =
     469=  Run RTEMS on other hypervisors  =
     470
     471
     472I start by explaining the build process in short, as this makes clear where to begin.
     473Then I show which files are necessary to have a look at and finish with an run through the different steps.
     474Due to the differences between the hypervisors, I only give a general overview.
     475
     476
     477RTEMS is build with for i386 and the virtualpok BSP.
     478The BSP requires a library implementing the virtualization layer functions.
     479The host has to implement the layer functions and provide the library as libpart.a in the virtpok/ directory.
     480At the current state the virtualization layer provides enough functionality to compile all testsuite/samples.
     481They will not all run, but ''Hello World'', ''Base_sp'' and ''Ticker'' should be working.
     482The ELF-binaries in the corresponding directories can now be used as guest binaries.
     483POK recognizes them as valid partition.
     484
     485
     486The virtualization layer is defined by two files: virtualizationlayercpu.h and virtualizationlayerbsp.h
     487The first defines the CPU related functions, mainly interrupt related, idle thread, fatal error handler.
     488The second defines the board services needed by the BSP; e.g. clock, console.
     489Copy these two files to your work directory on the hypervisor and implement these functions.
     490Compile these files and build a library including all hypervisor code needed (vCPU calls, VirtualMachineMonitor communication, etc.).
     491Then pass it over to RTEMS into c/src/lib/libbsp/i386/virtualpok/ as ''libpart.a''.
     492
     493Now it is time to configure and compile RTEMS.
     494Follow the instructions in the RTEMS manual.
     495To configure i386 and virtualpok make sure you find ''--target=i386-rtems4.11 --enable-rtemsbsp=virtualpok --enable-test'' in your configuration line.
     496The tests will compile the testsuite/samples.
     497
     498The binary in e.g. ''testsuite/samples/hello/hello.exe'' can now be used as virtual guest binary, able to communicate with your hypervisor.
     499
     500=  Port this approach to other architectures  =
     501
     502
     503I don't have a lot of knowledge about these architectures, so this HowTo is pretty abstract.
     504
     505First of all, you have to find out if your target architecture has so called "virtualization holes".
     506On x86 this are instructions which are able to be executed in a virtual environment, leading to a possible corruption of other virtual machines running on the hypervisor.
     507Find these functions in the RTEMS source code and come up with a possibility to redesign the CPU model of this architecture.
     508For i386 this led to a duplication of function guarded by a to be introduced configuration option.
     509A list of functions and files can be found above in the score-libcpu-split section.
     510When your architecture is fully virtualizable you are lucky, this will reduce the work.
     511
     512Other architectures do things in other ways.
     513The board will look different, so you need to have a look at the drivers necessary and who is providing them.
     514The console driver is pretty basic, as it just provides inchar and outchar capability.
     515The clock driver uses the standard RTEMS environment, shared across all BSPs.
     516Further, bsp_start() might change, as your architecture might not have an complicated IRQ management or you need more drivers, which need to be initialized at startup.
     517And don't forget the linkcmds.
     518In the best case you can just copy this from another BSP of this architecture.
    469519=  References  =
    470520
    471521<references/>
    472522
    473 =  Misc  =
     523
     524= Misc =
    474525
    475526''Under construction''