Re: What's kvmclock's custom sched_clock for?

[Marcelo Tosatti <mtosatti@redhat.com>]

On Fri, Jan 08, 2016 at 03:13:16PM +0100, Radim Krcmar wrote:
> 2016-01-07 18:10-0200, Marcelo Tosatti:
> > On Thu, Jan 07, 2016 at 04:18:11PM +0100, Radim Krcmar wrote:
> >> Stable sched clock is quite unrelated to TSC features.  KVMs from last
> >> few years should always give good enough result to allow stable sched
> >> clock.  We wanted realtime guests and realtime linux needs no_hz=full
> >> that depends on stable sched clock.  The result is huge hack.
> >> 
> >> We'd need to say that migration creates powerful gravity fields to
> >> faithfully migrate constant/invariant TSC, but stable sched clock
> >> doesn't have that strict expectations about time.
> > 
> > Was that supposed to be a joke?
> 
> Yes, if you mean the first sentence of the second paragraph.
> (I think that we'll use a different disclaimer when we enable
>  best-effort migration with invariant TSC.)

About getting rid of kvmclock, problem is steal time. Should
separate steal time reporting from rest of kvmclock, so that you
can use TSC clocksource and have steal time reporting.

Also, its very clear why migration was disabled, because 
invariant tsc man page says:

QEMU commit 68bfd0ad4a1dcc4c328d5db85dc746b49c1ec07e

    target-i386: block migration and savevm if invariant tsc is exposed

    Invariant TSC documentation mentions that "invariant TSC will run at
a
    constant rate in all ACPI P-, C-. and T-states".

    This is not the case if migration to a host with different TSC
frequency
    is allowed, or if savevm is performed. So block migration/savevm.

The issue is, even with migration to a host with 
proper frequency, TSC counting will stop for the duration of migration.

But i suppose you can document the fact (that "invariant TSC" behaviour
as documented is different than what exposed by virtualization), and 
go for it.