Re: [RFC] Paravirt timer for KVM

Gerd Hoffmann
2007-10-16T07:40:42Z

Glauber de Oliveira Costa wrote:
> Well, my previous understanding was that if the CPU marks the tsc as
> stable, it _won't_ stop even in C3, and it was done this way exactly
> to make sure there are a stable source for timing.

Other way around: Kernel can mark the TSC unstable if it figures it
does not tick on a constant rate (or if the kernel knows for certain
hardware it will not ...).

C3 on Intel hardware seems to be a known unstable case:

zweiblum kraxel ~# grep -A2 -B2 C3
/export/git/linux-2.6/arch/x86_64/kernel/tsc.c
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
#ifdef CONFIG_ACPI
/* But TSC doesn't tick in C3 so don't use it there */
if (acpi_gbl_FADT.header.length > 0 &&
acpi_gbl_FADT.C3latency < 1000)
return 1;
#endif

> But it does not really matter. We have two options:
> * Not considering tsc stable at all if sleeps, and then using the tsc
> just for adjustments.

Using the tsc for adjustments should do fine.

Xen updates the guest paravirt time with both systime and corrosponding
tsc timestamp, and the guest then uses the tsc delta to get more precise
time without having to ask the hypervisor each time.

If we take that scheme and additionally take care to update paravirt
time before re-running the guest after it went sleep for a while (and
thus the host might have been in C3) we should be set, right?

> * Considering the tsc stable, but taking the time the cpu spend
> sleeping into account, and returning some sorf of "return tsc +
> total_time_spent_sleeping_in_so_deep_sleep_states_such_as_C3" . I
> specially liked the naming.

I suspect that scheme would quickly becomes quite complex. For starters
consider that the TSC-stops-in-C3 behavior seems to apply to Intel
Hardware only ...

cheers,
Gerd