>> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know
>some
>> new chipsets implement rtc using HPET).
>
>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).

--Dor

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