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.
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.
Since one already has to use special timer parameters (-rtc-td-hack,
-no-kvm-pit-reinjection), using -no-hpet for problematic Linux
guests seems fine?
Depends on how common the problematic ones are. If they're common,
better to have a generic fix.
--
error compiling committee.c: too many arguments to function
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
