pvclock: reuse pvclock's functionality to convert tsc to nano

This patch provides a way to, given a measurement from tsc, acquire a nanosecond
figure. It works only for xen and kvm pvclocks, and I intend to use it for acquiring
early boot figures.

It is possible to measure the tsc frequency and with that figure out how to
convert a tsc read to nanoseconds, but I don't think we should pay that price.
Most of the pvclock drivers already provide that functionality, and we are not
planning that many users of that interface anyway.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
general infrastructure for boot time calculation

I am proposing a mechanism here that will allow us to have a better idea about
how much time do we spend booting, and also how much time each of the pieces
contribute to. For that, we need to be able to get time stamps really early, in
places where tracepoints may not be available, and a clock most definitely
won't.

With my proposal, one should be able to register events. After the system
boots, we will calculate the total time since the first event, as well as the
delta since the last event. If the first event is early enough, that should
produce a very good picture about our boot time.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
loader: measure some key points

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
boot: take early timings

In the past, we have struggled with long delays while reading data from disk in
real mode, leading to big boot times (not that they are totally gone). For that
reason, it is useful to know how much time is being spent in that process.  As
unstable and broken the TSC is, it is pretty much our only ally for that.

What I am proposing in this patch, is that we take timings from key states of
the bootloader, and pass that to main loader. We will do that by adding some
space at the end of the multiboot_info structure, so that we can pass some
fields to it. Right now, we are using 16 bytes so we can pass 2 64-bit tsc
reads.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
loader: add a bootchart option.

When booting with --bootchart, OSv will print a summary of where is our boot
time being spent up to the point right before our execution of main.

This mechanism can be extended later to keep measuring it later using other
facilities to account for the application, etc.

Example output:

OSv v0.05-156-gd3918a1
    disk read (real mode): 132.94ms, (+132.94ms)
    .init functions: 146.10ms, (+13.16ms)
    SMP launched: 147.57ms, (+1.47ms)
    RCU initialized: 150.61ms, (+3.04ms)
    VFS initialized: 154.08ms, (+3.46ms)
    Network initialized: 160.79ms, (+6.71ms)
    pvpanic done: 162.31ms, (+1.52ms)
    pci enumerated: 171.45ms, (+9.14ms)
    drivers probe: 171.46ms, (+0.02ms)
    drivers loaded: 182.52ms, (+11.06ms)
    ZFS mounted: 2116.32ms, (+1933.80ms)
    Total time: 2116.70ms, (+0.38ms)

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge branch 'boot-time-measurement'

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Conflicts:
	loader.cc