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