|
|
 |
|
IBM Research
| |
Research Hypervisor Hackers Guide $Id: HackersGuide.sgml,v 1.2 2005/02/16 18:42:32 jimix Exp $
The Research Hypervisor Project creates a Hypervisor environment that is suitable for
Client Operating System that have had minor changes applied to them in order
to run on the small number of machine abstractions the Hypervisor
presents. This is different than Hypervisors that emulate the
hardware completely so that no modifications to the Client Operating System
are necessary. Research Hypervisor Project uses what is popularly known as
"Para-Virtualization".
[1]
The main objective of this project is to create a coding base by
which the Hypervisor that is designed is easily portable to other
Instruction Set Architectures (ISA) as well be customized to
target a specific implementation of an ISA and therefore keep
the resulting code and binary as small as possible.
The Research Hypervisor Project is dedicated to the Open Source Movement and restricts
it primarily supports the features supported by popular Open
Source Friendly tools. The tools that are needed to get, configure,
build and test the Research Hypervisor is as follows:
- Source Controller Manager
Unless you got this from a tarball, you are probably
already familiar with our current SCM
which is (for various reasons) CVS. Anonymous access to the
repository is available to all and instructions can be
found on the project web page. Developer access is
restricted using SSH accounts in order to accept CVS
commits "if you have to ask.. you'll never
know".
- Compiler
Though the project adheres to the ANSI
C99 compiler, our reference
compiler is the GNU C Compiler and we use many
extensions that this compiler provides. However, in the
case where GCC allows several ways to do something
(eg. structure initializer notation) but the ANSI C99
Specification is explicit, the ANSI Spec shall be used.
- Linker, Assembler and Object Tools
The project uses and adheres to the System V ELF ABI as
defined for the processor that it is targeting. The
tools for generating and manipulating these object files
are supplied but the GNU
Binutils package.
- Cross Toolchain
It is expected that anytime the above tool-chain is
available to generate code for another host it is
expected to be use by Research Hypervisor. In fact most developers
usually build using Cross Compilers.
Any toolchain (cross or not) that is capable of building
a Linux kernel should be able to build Research Hypervisor. However,
the ELF specific tool-chain configurations (such as
i686-elf or powerpc-elf) are much simpler to build and
can be easily hosted on alternate development
environments including Apple's Mac OS X and Cygwin and
for this reason, their use is encouraged.
| Warning | It is known issue that the powerpc64-elf tool-chain
configuration has yet to exist for GCC, which is sad
since the powerpc64-linux GCC is the hardest to
build.
|
- Configuration
The GNU Autoconf
[2]
configuration tool is used in order describe the
specific processor and machine environment that Research Hypervisor
will be hosted on. Currently Autoconf Ver. 2.13 is only
supported, it is a low priority task to update to the
latest version.
The resulting configure script
depends on a small Unix like environment that is
restricted to POSIX features and any dependencies on
specific GNU extensions of those commands is purely
accidental.
- Build
Research Hypervisor uses the GNU Make, currently the known minimal
version is 3.79.1.
Note: It is a known problem that the current Makefiles do
not support Research Hypervisor to be built in parallel. It is also
desirable to design a Makefile infrastructure that is
not recursive. If these topics interest you please
contact a maintainer.
- Running
Currently the resulting binary hype
gets created in several forms that is usable by several
systems and simulators. Research Hypervisor runs on various hardware
[3]
machines. The project members acknowledge that it is
advantageous to be able to run on a simulator while
developing for Research Hypervisor. Simulators generally allow you to
run a specific build of Research Hypervisor anywhere as well as supply
the developer with a machine level hook to debug the
entire system. Frequently it is desirable to debug Research Hypervisor
in this manner if the bug can be reproduced in the
simulated environment.
The current X86 Research Hypervisor is known to work on BOCHS and
QEMU full system simulators and both run on several
platforms.
Note: It has also been shown that the Research Hypervisor can run in a
VMware partition.
The current PPC Research Hypervisor runs on the Mambo 970 simulator
that is currently available in binary only form.
- Thinwire
Thinwire
[4]
is a character IO transport that can use any single
transport to multiplex/de-multiplex several channels of
character IO. The protocol is a designed to work under
the worst conditions and is therefore slow and suitable
only for character IO. The transports used by Thinwire
vary from UARTs for HW, sockets for
Mambo, PTYs for BOCHS.
The other side of the transport will take all
the channels that are in use and open a listening socket
using a port value that is the channel number plus some
base offset. This listening socket can then be attached
to with telnet, GDB or any other
program that can interact with a socket to communicate
with a channel source within the Hypervisor.
- Debugger
The project is closely tied with to the GNU Project Debugger which
can be built as a cross platform debugger but more
importantly is capable of debugging remote victims.
Most of the Simulators used by this project allow for
GDB to control the simulated software. When on HW,
the Hypervisor core is completely debugable using a Thinwire
channel or other transport.
Note: The HW debugging is currently possible for PowerPC
targets and the x86 work is in progress.
Research Hypervisor source tree is organized with the following objectives in mind:
Isolation of the different modules. The source tree
contains
Build tools, TestOSes, plugins, and the Hypervisor core it is desirable to isolate the code that is
independent to the module and place the shared code in the
top level areas.
Maximal use of code sharing. Where generic code would be
automatically used unless a more customized
implementations exists.
To easily and accurately build the smallest most efficient
Hypervisor where the source files that are use to create it can
be easily identified and audited for security purposes.
The core Hypervisor is concerned with the partitioning of memory and
the accurate "time-slicing" of the processors.
Therefore the Hypervisor must not only be aware of the differences
in the ISA, but must be particularly aware of the
differences between the specific chip implementation. For
this reason we have organized the code in order to handle the
"grey area" that represents the similarities and
differences within the ISA.
Note: The directory structure is intended to only differentiate
between the processor features that allow for the
management of memory and scheduling. Code that handles
processor features that are not specific to the
core implementation should be
selected by the configuration system separately. An
example of this type of code would be the source that
saves and restores the VMX
PPC or the MMX2
IA32 registers.
The basic directory structure can be represented by the following:
./module/ISA/word-size/core/
The structure allows for a specific implementation of any
programming interface to be customized down to the definition
in the core/
directory.
Each directory component is described below.
This is the top-level of every module and the point where
code begins to appear. Prototypes of interfaces and type
definitions that are intended to be the same for all
architectures are defined at this level.
Note: Assembler files are rare at this level, and could only
be present if it defines a data area or the text defined
uses CPP macros that are defined for use at this level.
When the object tree (a.k.a. the "build tree")
has been configured and built for a specific machine, the
objects and resulting binaries can be found at this level.
The ISA directory is our first
level of specificity. It is here that the instruction set
and architected registers by the processor are known and
assembler statements in C files and assembler files begin to
appear.
The name used should describe the architecture in its most
generic form. Currently powerpc/ and x86 are used to differentiate
the use of those architectures.
Note: In the case of the Intel® 64 bit architecture, it is
expected that there would be an ./module/ia64/
directory introduced at this point, since it does define
a new architecture that only has a 64 bit
implementation.
The word-size directory is where
the "native machine word size" is defined. Any
any differences in the architecture relating to the code
that executes to take advantage of this difference.
Currently, the expectation is that we are only running
processors that are capable of 32 or 64 bits or both.
[5]
Important: It is by design that the code
assumes that this "machine word" is the
most efficient arithmetic integer size, is sufficient to
access all of addressable memory from the view of the
software program and can be expressed by a C pointer
type and the project base type
uval. See Base Types below.
The above assumption contribute to a programming model that
maximizes the portability objectives of Research Hypervisor and is
independent of the model used by the OSes running on top of
Hypervisor. However, it does specify the the use of registers
when an OS makes a call into the Hypervisor.
Note: In the case of the 64 bit extensions of the Intel® x86
architecture, it is expected that any 64 bit
specific details would be introduced in ./module/x86/64/.
Note: It is expected that any differences between the two
known 64 bit x86 architecture extensions (i.e. Intel®
EM64T and AMD Athelon/Hammer) shall be introduced in at
this level since they are indeed architecture. However,
specific core details would appear in the
core directories below.
This directory contains the lowest order code. The code
here represents the on chip nuances,
errata, work-a-rounds, of a specific implementation,
examples include:
The project is currently broken up into the following
directories that represent these "modules".
Starting at the top level the source tree we find the
introductory files to the source:
- ./DeadDirs
One of the problems with CVS is that it does not
handle the removal of directories very well. So
when a directory is removed it
needs to be removed from the repository and then all
developers that have commit access must remove the
directories in their own workspace. This will stop
the developer from accidentally reintroducing the
directory. Since this happens infrequently we keep
track of the directories we wish to delete (during
some synchronization point) in this file.
- ./autogen.sh
When a configure file or fragment is changed, that
is most files that end in
".in", the
autogen.sh shell script will
verify that the correct Autoconf version will be
used and will run Autoconf on all newer
configuration files in order to produce a final
configure script that is then
checked into the repository so that regular builders
of the project need not generate these files
themselves.
Note: This is the only program that actually makes
changes in the source tree and is really the
only exception to not
placing generated code in the source tree.
The ./hype/ directory
contains all sources that execute in the processor modes
designated as the domain of the Hypervisor.
The ./lib/ directory
is where the libhype.a static library
is defined. The library is intended for code that is used
by more that one module. The interfaces provided by
libhype.a are as follows.
Note: It is the hope of the maintainers to separate out the
above functionality into two separate libraries.
Unfortunately, the rules of binding several static ELF
libraries make the act of linking cumbersome and the
separation non-trivial.
The ./include/
directory contains the function prototypes and data
definitions that exist and used by the ./lib/ directory.
The ./test/ directory
contains a set of Small Client OS images that are designed
to test atomic features of the core Hypervisor. The Tesing OSes
are often referred to as "ToyOSes" and are
designed to be written almost like
standard C applications.
The specifics of this programming model is as follows:
the most important of them all is
controller.
The Controlling OS is the only OS that the core Hypervisor is
capable of loading. It is expected to be a binary
WOS
[6]
which is free of any ELF like file information.
Hypervisor expects to simply copy it into the first
partitioned area of memory and execute it at a known
location (normally 0x0) and an agreed
upon initial register state, which is ISA specific.
This ensures that Hypervisor is free of any knowledge of file
formats and simply consideres a well defined series of
bits.
Note: The configuration system allows you to choose an
alternate Controlling OS by using the
--with-controller=OS
Image. However, the
OS Image must loadable and
executable in the same way that
controller is.
By default the Controlling OS for Research Hypervisor is
controller.
The remainder of the Test OSes are collected together and
used to create and linkable object that represents an
array that contains the complete ELF image and a name
associated with it. This linkable object is then linked
into controller so controller can
create a new partition and load the Image into the
partition and cause it to be scheduled as specified by its
ELF information.
Note: It is possible to add other OS Images from
"outside" the project area (such as a
bootable Linux Kernel) and have it added to the list
of OSes that controller can spawn
controller. You can specify a list
of external images by using the configure option
--with-controller-images=FILE1[,FILE2,...]
Research Hypervisor uses the GNU Make (Minimum Version 3.79.1) and
|
|
|
