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:
499         do {
500                 seq = read_seqcount_begin(&tk_core.seq);
502                 ts->tv_sec = tk->xtime_sec;
503                 nsecs = timekeeping_get_ns(&tk->tkr);
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
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);
    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?


Reply via email to