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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux