-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
168 lines (119 loc) · 6.52 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
JAILHOUSE
=========
Jailhouse is a partitioning Hypervisor based on Linux. It is able to run
bare-metal applications or (adapted) operating systems besides Linux. For this
purpose it configures CPU and device virtualization features of the hardware
platform in a way that none of these domains, called "cells" here, can
interfere with each other in an unacceptable way.
Jailhouse is optimized for simplicity rather than feature richness. Unlike
full-featured Linux-based hypervisors like KVM or Xen, Jailhouse does not
support overcommitment of resources like CPUs, RAM or devices. It performs no
scheduling and only virtualizes those resources in software, that are essential
for a platform and cannot be partitioned in hardware.
Once Jailhouse is activated, it runs bare-metal, i.e. it takes full control
over the hardware and needs no external support. However, in contrast to other
bare-metal hypervisors, it is loaded and configured by a normal Linux system.
Its management interface is based on Linux infrastructure. So you boot Linux
first, then you enable Jailhouse and finally you split off parts of the
system's resources and assign them to additional cells.
WARNING: This is work in progress! Don't expect things to be complete in any
dimension. Use at your own risk. And keep the reset button in reach.
Community
---------
Project home: https://github.com/siemens/jailhouse
git: https://github.com/siemens/jailhouse.git
[email protected]:siemens/jailhouse.git
Mailing list: [email protected]
Subscription: [email protected]
https://groups.google.com/forum/#!forum/jailhouse-dev/join
Archives: http://news.gmane.org/gmane.linux.jailhouse
Requirements (preliminary)
--------------------------
currently:
- Intel x86 processor with support for 64-bit and VMX, more precisely
- EPT (extended page tables)
- unrestricted guest mode
- at least 2 logical CPUs
- x86-64 Linux kernel (tested against >= 3.9)
- VT-d usage has to be disabled in the Linux kernel, e.g. via command
line parameters:
intel_iommu=off intremap=off
upcoming:
- Intel IOMMU with interrupt remapping support
Build
-----
Simply run make, optionally specifying the target kernel directory:
make [KERNELDIR=/path/to/kernel/objects]
Note that the command line tool "jailhouse" requires a separate make run from
within the tools/ directory.
Configuration
-------------
Jailhouse requires one configuration file for the complete system and one for
each additional cell beside Linux. The configuration is currently being
defined manually by filling C structures. To study the structure, use
configs/qemu-vm.c for a system configuration and configs/apic-demo.c for a cell
configuration as reference. The build system will pick up every .c file from
the configs/ directory and generate a corresponding .cell file. .cell files can
then be passed to the jailhouse command line tool for enabling the hypervisor
and creating new cells.
Demonstration in QEMU/KVM
-------------------------
The included system configuration qemu-vm.c can be used to run Jailhouse in
QEMU/KVM virtual machine on Intel x86 hosts. Currently it requires kvm.git,
next branch on the host (in order to get support for guest activity state HLT).
3.14 is expected to include all necessary features for this setup. You also
need a Linux guest image with a recent kernel (tested with >= 3.9) and the
ability to build a module for this kernel. Make sure the kvm-intel module was
loaded with nested=1 to enable nested VMX support. Start the virtual machine as
follows:
qemu-system-x86_64 LinuxInstallation.img -m 1G -enable-kvm -smp 4 \
-cpu kvm64,-kvm_pv_eoi,-kvm_steal_time,-kvm_asyncpf,-kvmclock,+vmx,+x2apic \
-serial stdio -serial vc
Inside the VM, make sure that jailhouse.bin, generated by the build process,
is available for firmware loading (typically /lib/firmware).
The hypervisor requires a contiguous piece of RAM for itself and each
additional cell. This currently has to be pre-allocated during boot-up. So you
need to add
memmap=66M$0x3be00000
as parameter to the command line of the virtual machine's kernel. Reboot the
guest and load jailhouse.ko. Then enable Jailhouse like this:
jailhouse enable /path/to/qemu-vm.cell
Next you can create a cell with a demonstration application as follows:
jailhouse cell create /path/to/apic-demo.cell
jailhouse cell load apic-demo /path/to/apic-demo.bin -a 0xf0000
jailhouse cell start apic-demo
apic-demo.bin is left by the built process in the inmates/ directory. This
application will program the APIC timer interrupt to fire at 10 Hz, measuring
the jitter against the PM timer and displaying the result on the
console. Given that this demonstration runs in a virtual machine, obviously
no decent latencies should be expected.
To demonstrate the execution of a second, non-Linux cell, issue the following
commands:
jailhouse cell create /path/to/tiny-demo.cell
jailhouse cell load tiny-demo /path/to/tiny-demo.bin -a 0xf0000
jailhouse cell start tiny-demo
The tiny-demo will use the second serial port provided by QEMU. You will find
its output in a virtual console of the QEMU window.
After creation, cells are addressed via the command line tool by providing
their names or their runtime-assigned IDs. You can obtain information about
active cells this way:
jailhouse cell list
Cell destruction is performed by specifying the configuration file of the
desired cell. This command will destroy the apic-demo:
jailhouse cell destroy apic-demo
Note that the first destruction or shutdown request on the apic-demo cell will
fail. The reason is that this cell contains logic to demonstrate an ordered
shutdown as well as the ability of a cell to reject shutdown requests.
The apic-demo cell has another special property for demonstration purposes: As
long as it is running, no cell reconfigurations can be performed - the
apic-demo locks the hypervisor in this regard. In order to destroy another cell
or create an additional one, shut down the apic-demo first.
While cell configurations are locked, it is still possible, though, to reload
the content of existing cell (provided they accept their shutdown first). To
reload and restart the tiny-demo, issue the following commands:
jailhouse cell load tiny-demo /path/to/tiny-demo.bin -a 0xf0000
jailhouse cell start tiny-demo
Finally, Jailhouse is can be stopped completely again:
jailhouse disable
All non-Linux cells running at that point will be destroyed, and resources
will be returned to Linux.