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

[Radim Krcmar <rkrcmar@redhat.com>]

2016-01-12 18:48-0200, Marcelo Tosatti:
> On Tue, Jan 12, 2016 at 04:33:28PM +0100, Radim Krcmar wrote:
>> 2016-01-11 19:00-0200, Marcelo Tosatti:
>> > About getting rid of kvmclock,
>> 
>> I never wanted to get rid of kvmclock.  In the first part of the email
>> in question, I meant that the shift and scale can be accelerated by
>> VMX-TSC hardware, leaving only a check that kvmclock in expected mode
>> and rdtsc to get the result.
> 
> If host TSC can be used, then its not necessary to have the kvmclock
> complication.

Yes, it's just easier to have an indirection until all hosts can be
used.  (And that condition may never be true, so we'll just hide
obsoleted code in an unlikely path.)

>> >                                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.
>> 
>> We can already do that, steal time doesn't depend on guest sched clock.
>> Steal time uses a MSR+memory based interface that is related to kvmclock
>> only by shared notion of a second.
> 
> Err, i meant "guest stop notification" which is done via flags field.

True, we read the bit without looking at time, so a split wouldn't be
unnatural.  (The current code probably works with any clocksource if
kvmclock is set up first :/)