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