On 03/14/2010 12:27 PM, Avi Kivity wrote:
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.
It's all depends on how hard would it be to re-inject to windows guest.
We still need to fix the win2k3 64 bit and win2k8 64 bit (and not win7
as I told initially) since the irq is broadcasted to all the vcpus and
we do not track who acknowledged the irq.
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.
I meant a device that can be used to generate timeouts. We do use today
pit/rtc along with kvmclock time source but it's not perfect and
probably the same for hpet. This is why I tough that a pv device will be
beneficial.
--
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
