On Fri, Jan 20, 2012 at 11:22:27AM +0100, Jan Kiszka wrote:
> On 2012-01-20 11:14, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2012 at 07:01:44PM +0100, Jan Kiszka wrote:
> >> On 2012-01-19 18:53, Marcelo Tosatti wrote:
> >>>> What problems does it cause, and in which scenarios? Can't they be
> >>>> fixed?
> >>>
> >>> If the guest compensates for lost ticks, and KVM reinjects them, guest
> >>> time advances faster then it should, to the extent where NTP fails to
> >>> correct it. This is the case with RHEL4.
> >>>
> >>> But for example v2.4 kernel (or Windows with non-acpi HAL) do not
> >>> compensate. In that case you want KVM to reinject.
> >>>
> >>> I don't know of any other way to fix this.
> >>
> >> OK, i see. The old unsolved problem of guessing what is being executed.
> >>
> >> Then the next question is how and where to control this. Conceptually,
> >> there should rather be a global switch say "compensate for lost ticks of
> >> periodic timers: yes/no" - instead of a per-timer knob. Didn't we
> >> discussed something like this before?
> >
> > I don't see the advantage of a global control versus per device
> > control (in fact it lowers flexibility).
>
> Usability. Users should not have to care about individual tick-based
> clocks. They care about "my OS requires lost ticks compensation, yes or no".
FYI, at the libvirt level we model policy against individual timers, for
example:
<clock offset="localtime">
<timer name="rtc" tickpolicy="catchup" track="guest"/>
<timer name="pit" tickpolicy="delay"/>
</clock>
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
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
