cadets / freebsd-old

FreeBSD src tree http://www.FreeBSD.org/
Other
12 stars 7 forks source link

CADETS HyperTrace

This is the main source tree of HyperTrace, a CADETS-derived implementation of DTrace that supports tracing of virtual machines in real time. HyperTrace works much like present-day DTrace does, with a few minor user-visible changes.

Currently, HyperTrace only supports one mode of operation where the guest instruments itself and then uses a hypercall instruction (vmcall or vmmcall) to call back a DTrace probe to the host. Different modes of operation are planned, but not currently supported.

Changes from DTrace

High level changes:

dtrace(1) command line interface:

DTrace options:

dtraced transactional daemon:

Setup

At some point, there will be an ansible playbook for use on any machine. Presently, the playbooks we have are private and specific to our testing infrastructure. Once we've cleaned it up and have one ready for public consumption, it will be linked here. Until then, these are the steps necessary to set up HyperTrace manually:

First, build the source code:

make buildworld
make buildkernel

and follow the usual FreeBSD installation procedure from source.

make installkernel && reboot

Once you boot back in:

make installworld && reboot

With that, you should have HyperTrace installed. However, it is not yet ready for full use. Enable dtraced in /etc/rc.conf.

For host machine:

dtraced_enable="YES"
dtraced_type="overlord"

For guest machine:

dtraced_enable="YES"
dtraced_type="minion"

And then run

service dtraced start

You now have a fully functional HyperTrace installation. However, HyperTrace on its own is not terribly useful. You need some VMs. We suggest that for now, you just build a VM from the same source and follow the setup for guests described above using your preferred method.

Running things and Examples

Once you have a full HyperTrace setup, you are ready to run things! Try these example scripts to start with (make sure dtraced is running on both host and your guests).

Assuming ${TARGET} is set to the hostname or version of the OS you want to trace, or a valid glob:

dtrace -E -n "$TARGET:syscall:::entry { @[vmname, execname] = count(); }"
dtrace -E -n "$TARGET:syscall:::entry { @[curthread->td_ucred->cr_ruid, curthread->td_cred->cr_rgid] = count(); }"
dtrace -E -n "$TARGET:syscall:::entry { self->ts = timestamp; } $TARGET:syscall:::entry/self->ts/ { @[vmname, probefunc] = quantize(timestamp - self->ts); self->ts = 0; }"

Each of the above scripts demonstrates a couple of interesting properties. Firstly, we show a simple aggregation smoke-test. The second script shows that HyperTrace can correctly poke into guest memory with the right offsets for guest types, rather than using those on the host. Finally, the last script shows that HyperTrace can deal with collision of thread IDs in the kernel without being confused about namespaces across different guests (and the host). Furthermore, the timestamps gathered in the last script are in fact gathered on the host, so they don't suffer any of the traditional issues when it comes to time on virtual machines.

Source Code Guide

libdtrace (cddl/contrib/opensolaris/lib/libdtrace/common) changes:

New files:

There are plenty of changes in existing libdtrace files as well.

dtraced (cddl/contrib/opensolaris/cmd/dtraced):

dttransport (sys/dev/dttransport):

dtvirt (sys/cddl/dev/dtvirt):

virtio-dtrace:

hypertrace (sys/cddl/dev/hypertrace):

packet tagging:

Packet tagging includes many changes in various existing files revolving around networking, such as tap, tun, bpf, various mbuf copy routines and virtio-net.

dtracedctl (cddl/contrib/opensolaris/cmd/dtracedctl):

hypercall interface:

This functionality also involves heavy changes to the bhyve kernel module (vmm.ko).

Nested page table walk: