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 :/) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
