Newer
Older
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
# OSv
## Building
First, install prerequisite packages:
**Fedora**
```
yum install ant autoconf automake boost-static gcc-c++ genromfs libvirt libtool flex bison
```
**Debian**
```
apt-get install build-essential libboost-all-dev genromfs autoconf libtool openjdk-7-jdk ant
```
**Ubuntu users**: you may use [Oracle JDK][] if you don't want to pull too many
dependencies for ``openjdk-7-jdk``
[Oracle JDK]: https://launchpad.net/~webupd8team/+archive/java
To ensure functional C++11 support, Gcc 4.7 or above is required. Gcc 4.8 or
above is recommended, as this was the first version to fully comply with the
C++11 standard.
Make sure all git submodules are up-to-date:
```
git submodule update --init
```
Finally, build everything at once:
```
make external all
```
By default make creates image in qcow2 format. To change this pass format value via img_format variable, i.e.
```
make img_format=raw external all
```
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
## Running OSv
```
./scripts/run.py
```
By default, this runs OSv under KVM, with 4 VCPUs and 1GB of memory,
and runs the default management application (containing a shell, Web
server, and SSH server).
If running under KVM you can terminate by hitting Ctrl+A X.
## External Networking
To start osv with external networking:
```
sudo ./scripts/run.py -n -v
```
The -v is for kvm's vhost that provides better performance
and it's setup requires a tap and thus we use sudo.
By default OSv spawns a dhcpd that auto config the virtual nics.
Static config can be done within OSv, configure netwroking like so:
```
ifconfig virtio-net0 192.168.122.100 netmask 255.255.255.0 up
route add default gw 192.168.122.1
```
Test networking:
```
test TCPExternalCommunication
```
Running Java or C applications that already reside within the image:
```
# The default Java-based shell and web server
sudo scripts/run.py -nv -m4G -e "java.so -jar /usr/mgmt/web-1.0.0.jar app prod"
# One of the unit tests (compiled C++ code)
$ sudo scripts/run.py -nv -m4G -e "/tests/tst-pipe.so"
```
## Debugging
To build with debugging symbols, and preemption off (to not confuse gdb),
```
make mode=debug conf-preempt=0
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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
```
To clean debugging build's results, use
```
make clean mode=debug
```
To run the debugging build:
```
./scripts/run.py -d
```
To connect a debugger to this run:
```
$ gdb build/debug/loader.elf
(gdb) connect
(gdb) osv syms
(gdb) bt
```
To put a breakpoint early in the osv run, a useful trick is tell the vm to
reboot after setting the breakpoint:
```
(gdb) hbreak function_name
(gdb) monitor system_reset
(gdb) c
```
## Tracing
To add a static tracepoint, use the following code:
```c++
tracepoint<u64, int> trace_foo("foo", "x=%x y=%d");
void foo(u64 x, int y)
{
trace_foo(x, y);
// ...
}
```
where:
```
trace_foo: an internal identifier
"foo": a name for the tracepoint as will be visible in the log
<u64, int>: parameters for the tracepoint
"x=%x y=%d": format string for the tracepoint; size modifiers unneeded
```
To enable tracepoints at runtime, use the --trace= switch:
```
scripts/imgedit.py setargs build/release/loader.img --trace=sched\* testrunner.so
```
you can use multiple --trace= switches, or a single one with commas.
Shell-style wildcards allow enabling multiple tracepoints (as in the example).
If you add the --trace-backtrace switch, every tracepoint hit will also record
a stack backtrace.
To trace all function entries/returns in the program, build with conf-tracing=1
(clean build needed), and enable "function\*" tracepoints, with --trace=.
To view a trace, connect with gdb, and:
```
(gdb) osv syms
(gdb) set pagination off
(gdb) set logging on
(gdb) osv trace
```
gdb.txt will contain the the trace.
## Leak Detection
Memory allocation tracking can be enabled/disabled with the gdb commands
"osv leak on", "osv leak off", but even easier is to add the "--leak"
paramter to the loader, to have it start leak detection when entering the
payload (not during OSv boot). For example:
```
scripts/run.py -e "--leak java.so -jar cli.jar"
scripts/run.py -e "--leak tests/tst-leak.so"
```
Leak detection can be used in either the debug or release build, though
note that the release builds' optimizations may somewhat modify the
reported call traces.
When the run ends, connect to OSV with the debugger to see the where
the remaining allocation come from:
```
$ gdb build/release/loader.elf # or build/debug/loader.elf
(gdb) connect
(gdb) osv syms
(gdb) set logging on # optional, if you want to save the output to a file
(gdb) set height 0 # optional, useful if using "set logging on"
(gdb) osv leak show
```
Please note that "osv leak show" can take a L-O-N-G time - even a few
minutes, especially when running Java, as it allocates myriads of objects
that GDB will now have to inspect.
## Use-after-free and overrun detection
Set conf-debug_memory=1 in base.mak, and perform a clean build. A use-after-free will result
in an immediate segmentation fault.
Note that the detector requires a lot of memory, so you may need to start a larger guest.
## Running Java benchmarks
After running "make", do
```
./scripts/run.py -e "java.so -jar /tests/bench/bench.jar"
```
## Profiling
You can use ``perf kvm`` for profiling:
```
perf kvm --guestvmlinux=build/release/loader.elf top
```