Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-01-19 18:53, Marcelo Tosatti wrote:
>> What problems does it cause, and in which scenarios? Can't they be
>> fixed?
> 
> If the guest compensates for lost ticks, and KVM reinjects them, guest
> time advances faster then it should, to the extent where NTP fails to
> correct it. This is the case with RHEL4.
> 
> But for example v2.4 kernel (or Windows with non-acpi HAL) do not
> compensate. In that case you want KVM to reinject.
> 
> I don't know of any other way to fix this.

OK, i see. The old unsolved problem of guessing what is being executed.

Then the next question is how and where to control this. Conceptually,
there should rather be a global switch say "compensate for lost ticks of
periodic timers: yes/no" - instead of a per-timer knob. Didn't we
discussed something like this before?

What about periodic APIC tick compensation? I suppose the kernel does
not support this as no common guest makes use of this as clock source,
right? Or the HPET? Once the user space model supports compensation, we
need to control it as well. Individually?

I just want to avoid introducing an clumsy interface we then need to
maintain for a long time.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux