Re: [9front] qemu clock/timer issue

[Michael Forney <mforney@mforney.org>]

Jacob Moody <moody@posixcafe.org> wrote:
> It is understood that this bug only happens with intel kvm virtual machines.
>  From all that has been tested it was currently understood to affect newer intel machines.
> It seems however that your machine is a bit older(10+ years) and still triggering this.
> I've certainly run 9front in kvm on intel machines before so it is likely either
> something that changed with us or something that has changed with QEMU. My money
> is on some QEMU change.
> 
> If you do not feel comfortable debugging but would still be interested in helping
> perhaps you can help bisect 9front and qemu (one side at a time) to see if you can
> narrow down what has changed to get more information to fix these things.
> I would start with the nightly iso just to double check, then move back through the releases
> going back. Give that a go for a couple of them, then maybe try some older qemu.

If you look at my original mails, I had already bisected it to:
http://git.9front.org/plan9front/plan9front/a05bab362f66ddd6fa65f2e7cda9eaaa0217ec08/commit.html

This changes the mechanism by which CPU frequencies are detected
by default in 9front, and the timing/clock issues arise when the
frequency is detected incorrectly as 25MHz instead of 3.3GHz. The
issue went away when using *nohpet=1 to revert to i8253
clockinit/fastclock.

I wasn't able to explain why hpetcpufreq didn't work, but i8253cpufreq
did. They are both emulated with QEMU_CLOCK_VIRTUAL:
https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/hw/timer/hpet.c#L156
https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/hw/timer/i8254.c#L57-L58