On 03/14/2010 12:23 PM, Dor Laor wrote:
On 03/14/2010 09:10 AM, Gleb Natapov wrote:
On Sun, Mar 14, 2010 at 09:05:50AM +0200, Avi Kivity wrote:
On 03/11/2010 09:08 PM, Marcelo Tosatti wrote:
I have kept --no-hpet in my setup for
months...
Any details about the problems? HPET is important to some guests.
As Gleb mentioned in the other thread, reinjection will introduce
another set of problems.
Ideally all this timer related problems should be fixed by correlating
timer interrupts and time source reads.
This still needs reinjection (or slewing of the timer frequency).
Correlation doesn't fix drift.
But only when all time sources are synchronised and correlated with
interrupts we can slew time frequency without guest noticing (and only
if guest disables NTP)
In the mean time we should definitely disable hpet by default.
Definitely not. Windows needs it. Some pre-kvmclock Linux may also
work with it.
Without hpet, there is no fast high resolution timer in the system.
Besides this we need to fully virtualize the tsc, fix win7 64bit rtc
time drift and some pvclock potential issues. Before we add new timer,
better fix existing ones.
What about creating a pv time keeping device that will be aware of
lost ticks and host wall clock time? It's similar to hyper-v
enlightenment virt timers.
That's kvmclock.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
