]> rtime.felk.cvut.cz Git - jailhouse.git/blob - README.md
ea70d2f2c4c9e2528ba8ef7baab591bd31cbc2d3
[jailhouse.git] / README.md
1 JAILHOUSE
2 =========
3
4 Jailhouse is a partitioning Hypervisor based on Linux. It is able to run
5 bare-metal applications or (adapted) operating systems besides Linux. For this
6 purpose it configures CPU and device virtualization features of the hardware
7 platform in a way that none of these domains, called "cells" here, can
8 interfere with each other in an unacceptable way.
9
10 Jailhouse is optimized for simplicity rather than feature richness. Unlike
11 full-featured Linux-based hypervisors like KVM or Xen, Jailhouse does not
12 support overcommitment of resources like CPUs, RAM or devices. It performs no
13 scheduling and only virtualizes those resources in software, that are essential
14 for a platform and cannot be partitioned in hardware.
15
16 Once Jailhouse is activated, it runs bare-metal, i.e. it takes full control
17 over the hardware and needs no external support. However, in contrast to other
18 bare-metal hypervisors, it is loaded and configured by a normal Linux system.
19 Its management interface is based on Linux infrastructure. So you boot Linux
20 first, then you enable Jailhouse and finally you split off parts of the
21 system's resources and assign them to additional cells.
22
23
24 WARNING: This is work in progress! Don't expect things to be complete in any
25 dimension. Use at your own risk. And keep the reset button in reach.
26
27
28 Community Resources
29 -------------------
30
31 Project home:
32
33  - https://github.com/siemens/jailhouse
34
35 Source code:
36
37  - https://github.com/siemens/jailhouse.git
38  - git@github.com:siemens/jailhouse.git
39
40 Mailing list:
41
42   - jailhouse-dev@googlegroups.com
43
44   - Subscription:
45     - jailhouse-dev+subscribe@googlegroups.com
46     - https://groups.google.com/forum/#!forum/jailhouse-dev/join
47
48   - Archives
49     - http://news.gmane.org/gmane.linux.jailhouse
50
51 Continuous integration:
52
53   - https://travis-ci.org/siemens/jailhouse
54
55   - Status:
56     - ![](https://travis-ci.org/siemens/jailhouse.svg?branch=master) on master
57     - ![](https://travis-ci.org/siemens/jailhouse.svg?branch=next) on next
58
59 Static code analysis:
60
61   - https://scan.coverity.com/projects/4114
62
63   - Status:
64     - ![](https://scan.coverity.com/projects/4114/badge.svg) on coverity_scan
65
66 See the [contribution documentation](CONTRIBUTING.md) for details
67 on how to write Jailhouse patches and propose them for upstream integration.
68
69
70 Requirements (preliminary)
71 --------------------------
72
73 x86 architecture:
74
75   - Intel system:
76
77     - support for 64-bit and VMX, more precisely
78       - EPT (extended page tables)
79       - unrestricted guest mode
80       - preemption timer
81
82     - Intel IOMMU (VT-d) with interrupt remapping support
83       (except when running inside QEMU)
84
85   - or AMD system:
86
87     - support for 64-bit and SVM (AMD-V), and also
88       - NPT (nested page tables); required
89       - Decode Assists; recommended
90
91     - AMD IOMMU (AMD-Vi) is unsupported now but will be required in future
92
93   - at least 2 logical CPUs
94
95   - x86-64 Linux kernel (tested against >= 3.14)
96
97     - VT-d IOMMU usage (DMAR) has to be disabled in the Linux kernel, e.g. via
98       the command line parameter:
99
100           intel_iommu=off
101
102     - To exploit the faster x2APIC, interrupt remapping needs to be on in the
103       kernel (check for CONFIG_IRQ_REMAP)
104
105 ARM architecture:
106
107   - Abstract:
108
109     - ARMv7 with virtualization extensions
110
111     - Appropriate boot loader support (typically U-Boot)
112       - Linux is started in HYP mode
113       - PSCI support for CPU offlining
114
115     - at least 2 logical CPUs
116
117   - Board support:
118
119     - Banana Pi (see also [below](#setup-on-banana-pi-arm-board))
120
121     - ARM Versatile Express with Cortex-A15 or A7 cores
122       (includes ARM Fast Model)
123
124
125 Build & Installation
126 --------------------
127
128 Simply run make, optionally specifying the target kernel directory:
129
130     make [KDIR=/path/to/kernel/objects]
131
132 Except for the hypervisor image `jailhouse*.bin` that has to be available in the
133 firmware search path (invoke `make firmware_install` for this), you can run
134 Jailhouse from the build directory. Alternatively, install everything on the
135 target machine by calling `make install` from the top-level directory.
136
137
138 Configuration
139 -------------
140
141 Jailhouse requires one configuration file for the complete system and one for
142 each additional cell beside Linux. The configuration is currently being
143 defined manually by filling C structures. To study the structure, use
144 configs/qemu-vm.c for a system configuration and configs/apic-demo.c for a cell
145 configuration as reference. The build system will pick up every .c file from
146 the configs/ directory and generate a corresponding .cell file. .cell files can
147 then be passed to the jailhouse command line tool for enabling the hypervisor
148 and creating new cells.
149
150
151 Demonstration in QEMU/KVM
152 -------------------------
153
154 The included system configuration qemu-vm.c can be used to run Jailhouse in
155 QEMU/KVM virtual machine on x86 hosts (Intel and AMD are supported). Currently
156 it requires Linux 3.18 or newer on the host side (Intel is fine with 3.17).
157 QEMU is required in a recent version (2.1) as well if you want to use the
158 configuration file included in the source tree.
159
160 You also need a Linux guest image with a recent kernel (tested with >= 3.9) and
161 the ability to build a module for this kernel. Further steps depend on the type
162 of CPU you have on your system.
163
164 For Intel CPUs: Make sure the kvm-intel module was loaded with nested=1 to
165 enable nested VMX support. Start the virtual machine as follows:
166
167     qemu-system-x86_64 -machine q35 -m 1G -enable-kvm -smp 4 \
168         -cpu kvm64,-kvm_pv_eoi,-kvm_steal_time,-kvm_asyncpf,-kvmclock,+vmx,+x2apic \
169         -drive file=LinuxInstallation.img,id=disk,if=none \
170         -device ide-hd,drive=disk -serial stdio -serial vc \
171         -device intel-hda,addr=1b.0 -device hda-duplex
172
173 For AMD CPUs: Make sure the kvm-amd module was loaded with nested=1 to enable
174 nested SVM support. Start the virtual machine as follows:
175
176     qemu-system-x86_64 -machine q35 -m 1G -enable-kvm -smp 4 \
177         -cpu host,-kvm_pv_eoi,-kvm_steal_time,-kvm_asyncpf,-kvmclock,+svm,+x2apic \
178         -drive file=LinuxInstallation.img,id=disk,if=none \
179         -device ide-hd,drive=disk -serial stdio -serial vc \
180         -device intel-hda,addr=1b.0 -device hda-duplex
181
182 Inside the VM, make sure that jailhouse-*.bin, generated by the build process,
183 are available for firmware loading (typically /lib/firmware), see above for
184 installation steps.
185
186 The hypervisor requires a contiguous piece of RAM for itself and each
187 additional cell. This currently has to be pre-allocated during boot-up. So you
188 need to add
189
190     memmap=66M$0x3b000000
191
192 as parameter to the command line of the virtual machine's kernel. Reboot the
193 guest and load jailhouse.ko. Then enable Jailhouse like this:
194
195     jailhouse enable /path/to/qemu-vm.cell
196
197 Next you can create a cell with a demonstration application as follows:
198
199     jailhouse cell create /path/to/apic-demo.cell
200     jailhouse cell load apic-demo /path/to/apic-demo.bin -a 0xf0000
201     jailhouse cell start apic-demo
202
203 apic-demo.bin is left by the built process in the inmates/demos/x86 directory.
204 This application will program the APIC timer interrupt to fire at 10 Hz,
205 measuring the jitter against the PM timer and displaying the result on the
206 console. Given that this demonstration runs in a virtual machine, obviously
207 no decent latencies should be expected.
208
209 After creation, cells are addressed via the command line tool by providing
210 their names or their runtime-assigned IDs. You can obtain information about
211 active cells this way:
212
213     jailhouse cell list
214
215 Cell destruction is performed by specifying the configuration file of the
216 desired cell. This command will destroy the apic-demo:
217
218     jailhouse cell destroy apic-demo
219
220 Note that the first destruction or shutdown request on the apic-demo cell will
221 fail. The reason is that this cell contains logic to demonstrate an ordered
222 shutdown as well as the ability of a cell to reject shutdown requests.
223
224 The apic-demo cell has another special property for demonstration purposes: As
225 long as it is running, no cell reconfigurations can be performed - the
226 apic-demo locks the hypervisor in this regard. In order to destroy another cell
227 or create an additional one, shut down the apic-demo first.
228
229     jailhouse cell shutdown apic-demo  # call again if error is returned
230
231 To demonstrate the execution of a second, non-Linux cell, issue the following
232 commands:
233
234     jailhouse cell create /path/to/pci-demo.cell
235     jailhouse cell load pci-demo /path/to/pci-demo.bin -a 0xf0000
236     jailhouse cell start pci-demo
237
238 The pci-demo will use the second serial port provided by QEMU. You will find
239 its output in a virtual console of the QEMU window. The purpose of this demo is
240 to show basic PCI device configuration and MSI handling.
241
242 While cell configurations are locked, it is still possible, though, to reload
243 the content of existing cell (provided they accept their shutdown first). To
244 reload and restart the tiny-demo, issue the following commands:
245
246     jailhouse cell start apic-demo
247     jailhouse cell load pci-demo /path/to/pci-demo.bin -a 0xf0000
248     jailhouse cell start pci-demo
249
250 Finally, Jailhouse is can be stopped completely again:
251
252     jailhouse disable  # call again on error due to running apic-demo
253
254 All non-Linux cells running at that point will be destroyed, and resources
255 will be returned to Linux.
256
257
258 Setup on Banana Pi ARM board
259 ----------------------------
260
261 The Banana Pi is a cheap Raspberry-Pi-like ARM board with an Allwinner A20 SoC
262 (dual-core Cortex-A7). It runs mainline Linux kernels and U-Boot and is
263 comparably well hackable. Further information can be found on
264 http://linux-sunxi.org.
265
266 For Jailhouse, a U-Boot (pre-)release more recent than v2015.04-rc1 is
267 required. Tested and know to work is git revision bd2a4888b1.
268
269 The Linux kernel version should be at least 3.19-rcX. The configuration used
270 for continuous integration builds can serve as reference, see
271 `ci/kernel-config-banana-pi`. The kernel has to be booted with the following
272 additional parameters, e.g. by adjusting the U-Boot environment accordingly:
273
274     mem=958M vmalloc=512M
275
276 The recommended cross-toolchain is available from Linaro, see
277 http://www.linaro.org/downloads.
278
279 Before building Jailhouse, copy the configuration header file
280 `ci/jailhouse-config-banana-pi.h` to `hypervisor/include/jailhouse/config.h`.
281 Then run make:
282
283     make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- \
284          KDIR=/path/to/arm-kernel/objects
285
286 Binaries can be installed directly to the target root file system if it is
287 mounted on the host:
288
289     make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- \
290          KDIR=/path/to/arm-kernel/objects DESTDIR=/mount-point install
291
292 Cell configurations and demo inmates will not be installed this way and have to
293 be transferred manually as needed. Make sure you have `configs/bananapi.cell`
294 and, as desired, the inmates configs (`configs/bananapi-*.cell`) and binaries
295 (`inmates/demos/arm/*.bin`) available on the target.
296
297 Jailhouse and inmates are started on ARM just like on x86. The only difference
298 is that inmates have to be loaded at offset 0. Just leave out the `-a`
299 parameter when invoking `jailhouse cell load`.