468 | | |
| 468 | = HowTo = |
| 469 | = Run RTEMS on other hypervisors = |
| 470 | |
| 471 | |
| 472 | I start by explaining the build process in short, as this makes clear where to begin. |
| 473 | Then I show which files are necessary to have a look at and finish with an run through the different steps. |
| 474 | Due to the differences between the hypervisors, I only give a general overview. |
| 475 | |
| 476 | |
| 477 | RTEMS is build with for i386 and the virtualpok BSP. |
| 478 | The BSP requires a library implementing the virtualization layer functions. |
| 479 | The host has to implement the layer functions and provide the library as libpart.a in the virtpok/ directory. |
| 480 | At the current state the virtualization layer provides enough functionality to compile all testsuite/samples. |
| 481 | They will not all run, but ''Hello World'', ''Base_sp'' and ''Ticker'' should be working. |
| 482 | The ELF-binaries in the corresponding directories can now be used as guest binaries. |
| 483 | POK recognizes them as valid partition. |
| 484 | |
| 485 | |
| 486 | The virtualization layer is defined by two files: virtualizationlayercpu.h and virtualizationlayerbsp.h |
| 487 | The first defines the CPU related functions, mainly interrupt related, idle thread, fatal error handler. |
| 488 | The second defines the board services needed by the BSP; e.g. clock, console. |
| 489 | Copy these two files to your work directory on the hypervisor and implement these functions. |
| 490 | Compile these files and build a library including all hypervisor code needed (vCPU calls, VirtualMachineMonitor communication, etc.). |
| 491 | Then pass it over to RTEMS into c/src/lib/libbsp/i386/virtualpok/ as ''libpart.a''. |
| 492 | |
| 493 | Now it is time to configure and compile RTEMS. |
| 494 | Follow the instructions in the RTEMS manual. |
| 495 | To configure i386 and virtualpok make sure you find ''--target=i386-rtems4.11 --enable-rtemsbsp=virtualpok --enable-test'' in your configuration line. |
| 496 | The tests will compile the testsuite/samples. |
| 497 | |
| 498 | The 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 | |
| 503 | I don't have a lot of knowledge about these architectures, so this HowTo is pretty abstract. |
| 504 | |
| 505 | First of all, you have to find out if your target architecture has so called "virtualization holes". |
| 506 | On 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. |
| 507 | Find these functions in the RTEMS source code and come up with a possibility to redesign the CPU model of this architecture. |
| 508 | For i386 this led to a duplication of function guarded by a to be introduced configuration option. |
| 509 | A list of functions and files can be found above in the score-libcpu-split section. |
| 510 | When your architecture is fully virtualizable you are lucky, this will reduce the work. |
| 511 | |
| 512 | Other architectures do things in other ways. |
| 513 | The board will look different, so you need to have a look at the drivers necessary and who is providing them. |
| 514 | The console driver is pretty basic, as it just provides inchar and outchar capability. |
| 515 | The clock driver uses the standard RTEMS environment, shared across all BSPs. |
| 516 | Further, 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. |
| 517 | And don't forget the linkcmds. |
| 518 | In the best case you can just copy this from another BSP of this architecture. |