>>> Basically HPET can operate in legacy mode - where it uses the same
>>> IRQ as the RTC (and RTC won't deliver any interrupt) - or in
>>> "standard" mode where the IO-APIC can be configured to deliver the
>>> interrupt on any line. ATM Linux can only use the legacy mode.
>>> You can of course disable HPET, but then it won't be available for
>>> in-kernel timekeeping (in case e.g. the TSC is not stable/synced).
>>> I'd rather add support for HPET as timer in QEMU...
>>> On the original issue: if the host is running at HZ=100 then the
>>> precision of the timer may be a awkward (usually around 20ms), but
>>> it's surprising that it causes such a huge drift.
>>
>> We're experiencing guest clock drifts even when the host is
>> running with HZ=1000.
>> But so far there were no performance problmes around it.
>> It's worth a shot anyway.
>>
>> Another option is to use -tdf for qemu command line (stands
>> for TimeDriftFix).
>> The option make qemu push more pit irqs to the guest until the
>> required ack number is reached.
>>
>> For the general case there is work in progress to fix these
>> types of timing issues.
>> We intend to do the following:
>> 1. Make qemu support dyn-tick (almost done)
>> 2. Add compensation support for all guest time sources (pit, acpi,..)
>> 3. Add kernel ioctl command to receive accurate time source (based on
>>   hrtimer) for hosts without dyn-tick (which provides accurate high
>> precision user space timers).
>>
>Even with this, the guest time will still have 20-30% drift since Linux
>guest TSC handler
>will cross refer the PIT irq with TSC value to pick up the lost ticks
>which works fine for
>native but bring many un necessary compensation in guest side.
Simplying
>adding
>compensation timer irq to guest solve part of the issues, but still
>painful. Xen took an
>aggresive approach to fix this by precisely sync guest time resource
>together such as
>PIT, TSC, RTC etc. But it is too complicated and still doesn;t solve
the
>whole
>problem in SMP situation, it may be not necessay in KVM.

You're right that we need to sync all time sources, I just want to start
with the first.
Since non-acpi windows uses PIT we chose to start with it.

>
>BTW, Vmware also has similar time virtualization issue. pv TSC time
>resource may solve
>this issue finally.

It should also work for HVMs. I know that VMware also changed ntp,
probably because
their virtualize time is not perfect.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to