Re: [PATCH] Implement timekeeping for rumprun/hw (x86)

  • From: Antti Kantee <pooka@xxxxxx>
  • To: rumpkernel-users@xxxxxxxxxxxxx
  • Date: Mon, 06 Jul 2015 12:20:49 +0000

On 06/07/15 11:47, Martin Lucina wrote:

On Monday, 06.07.2015 at 11:23, Antti Kantee wrote:
On 06/07/15 10:50, Martin Lucina wrote:
On Monday, 06.07.2015 at 10:35, Antti Kantee wrote:
While that may be a fix, how can that even in theory be a fix for
the guest clock running at 2/5 speed compared to the real world??

The problem I was trying to fix was sleeps being
way too long on x86-64 (as reported by the test program).

The problem I reported: "The clock seems to run at about 2/5 speed
under no-kvm QEMU (i.e. sleep 2 takes ~5 seconds). Is that
expected?" I assumed you were fixing the reported problem.

Ah, right. Well, I can't reproduce that here at all :-(

Bummer. I'm not too concerned if it's only the qemu on my system, but as things go, usually no such luck.

Can anyone else confirm or refute? Here's my test program:

=== snip ===
int
main()
{

for (;;) {
printf("foo\n");
sleep(1);
}
}
=== snip ===

Tested with QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12~bpo70+1).

I've been testing with QEMU in kvm and non-kvm mode, tried the command line
manually, ... What is interesting is that my QEMU does not document a
"no-kvm" option but it does seem to accept it. I'll triple check again that
I'm not running in KVM mode all the time by accident, perhaps by booting
with the kvm module blacklisted or something.

IIRC -no-kvm is a deprecated option, but travis qemu needs it (then again, I might remember completely wrong).

The best way to check that you're not using KVM is to boot a full OS guest and see if it launches in under 5 minutes ;)

Other related posts: