On 13.01.2015 22:16, Paolo Bonzini wrote:
On 13/01/2015 22:14, Gerhard Wiesinger wrote:
I also had a look at the kernel code again:
http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493
499 do {
500 seq = read_seqcount_begin(&tk_core.seq);
501
502 ts->tv_sec = tk->xtime_sec;
503 nsecs = timekeeping_get_ns(&tk->tkr);
504
505 } while (read_seqcount_retry(&tk_core.seq, seq));
So it looks like that the seqcount always changes and therefore loops
forever here (as far as I digged it down this is the only loop here).
Might be something wrong with the memory barriers in recent qemu-kvm
releases?
No, that's not possible. Unless you pause/resume or migrate the VM, all
of the handling of kvmclock is entirely in the kernel.
Any other possible explaination of the problem?
Had a look at the diff (I guess the right file at least in qemu tree):
# no critical changes IHMO here
git diff -u v1.6.2..v2.1.2 ./hw/i386/kvm/clock.c
Trying to reproduce with a loop:
#include <sys/time.h>
#include <stdio.h>
int main(int argc, char* argv[])
{
struct timeval tv;
int i = 0;
for (;;)
{
gettimeofday(&tv, 0);
++i;
if (i >= 10000000)
{
i = 0;
printf("%i\n", (int)tv.tv_sec);
}
}
return 0;
}
As I wrote this: "First tests seem to run well, so no quick win ....", I
could reproduce it with a stall in 318s :-)
(gdb) bt
#0 0x00007fff6d9fefff in gettimeofday ()
#1 0x00000000004005ad in main (argc=1, argv=0x7fff6d9b28b8) at
gettimeofdayloop.c:10
So we have at least a testcase which is quickly to reproduce.
So we are digging down my second findings about a major bug in qemu-kvm :-)
Can someone try, too?
Ciao,
Gerhard
