Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?

[Marcelo Tosatti <mtosatti@redhat.com>]

On Thu, Jan 19, 2012 at 06:38:01PM +0100, Jan Kiszka wrote:
> On 2012-01-19 18:25, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote:
> >> Hi all,
> >>
> >> I've finished a first version of cleaned-up in-kernel KVM PIT support.
> >> That will be rolled out once the base support for irqchip has been merged.
> >>
> >> I'm now wondering if and how to model two control knobs we have in qemu-kvm:
> >>
> >>  o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC
> >>    are kernel based (default: off, ie. use in-kernel PIT)
> > 
> > It can be useful for debugging.
> 
> When was it last? The kernel model should be stable by now, just
> possibly incomplete. But then there is still the full emulation in user
> mode, available via kernel_irqchip=off.
> 
> We can control it, the question is if we really need the granularity.

Right, that should be enough.

> 
> > 
> >>  o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection
> >>    logic in the kernel (default: off, ie. do reinject)
> > 
> > If the guest kernel does not compensate for lost ticks, reinjection is 
> > needed. Otherwise, it might cause problems.
> 
> That's why it's /on/ by default? 

Its on by default because it was the default before the option 
was introduced.

> 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.