[EMAIL PROTECTED] wrote: >>> 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). > 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.
BTW, Vmware also has similar time virtualization issue. pv TSC time resource may solve this issue finally. thx,eddie ------------------------------------------------------------------------- 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
