[hypervisor][time] Add support for KVM CLOCK_PAIRING hypercall

The hypercall allows to provide the guest with mapping of tsc to
wall time at some moment in time, so in the way it's the same as
boot time provided by pvclock.

Hypercall itself is not particularly interesting, but linux calls
it when kvmclock based PTP clock is enabled in the guest, which
happens for default debian_guest kernel for example. However, since
hypervisor doesn't handle VMCALL exits it fails. In general we
should not stop hypervisor on VMCALL VM exits, instead we should
return error to the guest indicating that hypercall is not supported.

Test: buildall, manually run debian_guest on Intel NUC
MAC-158 #comment In Progress

Change-Id: I79c28df80a23df6bcda8737305e6a6b169b67d78

[x86][hypervisor] Zero pvclock structures

This ensures that we reset the pvclock structures to a known state when
we first use them.

Change-Id: Ie0c902751573dbeede50557388b925f269acb47a

[x86][hypervisor] Check clocksource is stable once

When we first create a VCPU, check whether the clocksource is stable.
This saves us from checking each time we update the system time.

Change-Id: I3eed90ea22ad0237abdea54220953c8206761499

[pvclock] Set and test for stable clocksource

This allows us to query for whether the pvclock is stable, and then use
that to decide whether to default to TSC as the wall-clock.

Change-Id: I564df4537466b5eac4391a67671e88ba1e7a2ba4

[kernel][timer] Calibrate TSC with paravirtualized clock

Adds some support for KVM/PV clock. Currently only calibrating the TSC
via the information in the system time struct. This allows the
hypervisor to host Zircon while nested in KVM without implementing the
PIT timer.

Change-Id: I63f0961112b56dd09b1bc893b74f2646d844d7aa

[lib][hypervisor] Move everything into a namespace

Move everything, but vmm_guest_page_fault_handler, into the hypervisor
namespace.

Change-Id: Ied96a7945b26c4a1ed24c03b293d42c7d89e7812

[x86][hypervisor] Simplify pvclock and guest_ptr

Change the way we map guest-physical to host-virtual so it's a bit
simpler and harder to make a mistake when using.

Change-Id: Ib65bd48c14414a6ddfd7b07233e0b3e3540f9c20

[kernel][hypervisor] KVM clock support in hypervisor

KVM/Xen paravirtualized clock API consists of monotonic clock
source (we refer to it as system time) and fixed point in time
(we refer to it as boot time), and boot time + system time should
give current wall time. Since system time is supposed to be
monotonic it means that boot time may be adjusted (for example,
by NTP) and therefore we use sys_get_clock to get boot time.

System time is exported per VCPU and periodically updated by host.
TSC is used to adjust system time value in the guest between
those updates. We update system time on VCPU resume.

Getting system time in the guest is expected to be fast, but boot
time on the other hand is not expected to be fast and only
guaranteed to be updated by host after MSR write from guest and
therefore incurs vmexit. Despite the name boot time doesn't need
to be guest boot time. In KVM it's actually host boot time and we
use the same boot time for this implementation.

And one comment regarding naming. KVM and Xen use the same
structures layout for paravirtualized clock, but KVM uses MSRs
to communicate with guests and Xen uses PV ops for that. So data
strcutures are common and use prefix pv or Pv, while constants
describing MSRs and KVM specific flags use Kvm prefix.

Change-Id: I81cdbd893985ad17bcf5f163e652ec1bb63feacb