Re: [9front] qemu clock/timer issue

[Nick Owens <mischief@offblast.org>]

kvm emulates a local APIC timer which the 9front kernel uses. the
timer period is clamped to a minimum period, and my understanding is
that the purpose is to protect the host from CPU consumption by
guests, but i don't have a citation for that. 9front requests a timer
period shorter than what the default minimum is and kvm warns about
it. it maybe needs more investigation as to whether we really need
such short timers.

in the meantime, you can lower the timer period minimum with

echo "options kvm min_timer_period_us=10" >> /etc/modprobe.d/kvm.conf

which is 10000ns. it won't kill all of the warnings since sometimes
the timer period is slightly shorter, but it will help with the dmesg
spam.

On Sat, Feb 5, 2022 at 7:30 AM Michael Forney <mforney@mforney.org> wrote:
>
> I was recently running 9front in a VM on linux (qemu, with
> -enable-kvm), and noticed several weird timing/clock issues. The date
> command gives wildly varying results +- 1 minute:
>
> cpu% date
> Fri Feb  4 17:39:23 PST 2022
> cpu% date
> Fri Feb  4 17:39:12 PST 2022
> cpu% date
> Fri Feb  4 17:40:19 PST 2022
> cpu% date
> Fri Feb  4 17:39:18 PST 2022
>
> `sleep 1` exits pretty much instantly, stats moves through the entire
> width in a second or two, and clicking in scrollbars starts repeating
> immediately.
>
> I notice the following messages in my dmesg:
> kvm: vcpu 3: requested 38141 ns lapic timer period limited to 200000 ns
> kvm: vcpu 1: requested 9449 ns lapic timer period limited to 200000 ns
> kvm: vcpu 2: requested 51204 ns lapic timer period limited to 200000 ns
> kvm: vcpu 0: requested 74421 ns lapic timer period limited to 200000 ns
>
> I don't remember this problem last time I ran 9front in qemu (around a
> year ago), so I looked through commit history and found one commit
> that seemed like it might be related:
> http://git.9front.org/plan9front/plan9front/a05bab362f66ddd6fa65f2e7cda9eaaa0217ec08/commit.html
>
> To check, I tried setting *nohpet=1 in my plan9.ini, which *seems* to
> have solved the problem, though I still see those same messages in
> dmesg on the linux host (but now the requested lapic timer period is
> always around 100000 ns or greater).
>
> Anyone know what's going on here?