Re: [Qemu-devel] [PATCH v3 00/11] MTTCG fix-ups for 2.9

[Alex Bennée]

Pavel Dovgalyuk <address@hidden> writes:

>> From: Alex Bennée [mailto:address@hidden
>> Pavel Dovgalyuk <address@hidden> writes:
>> >> From: Alex Bennée [mailto:address@hidden
>> >> Pavel Dovgalyuk <address@hidden> writes:
>> >
>> >> I ran the following test on both pre-mttcg-merge and my current HEAD
>> >> which includes Paolo's fix series:
>> >>
>> >>  ./arm-softmmu/qemu-system-arm -machine type=virt \
>> >>     -display none -smp 1 -m 4096 -cpu cortex-a15 \
>> >>     -kernel ../images/aarch32-current-linux-initrd-guest.img
>> >>     -append "console=ttyAMA0" -serial mon:stdio \
>> >>     -net none \
>> >>     -icount shift=7,rr=record,rrfile=replay.bin
>> >>
>> >> And then:
>> >>
>> >>  ./arm-softmmu/qemu-system-arm -machine type=virt \
>> >>     -display none -smp 1 -m 4096 -cpu cortex-a15 \
>> >>     -kernel ../images/aarch32-current-linux-initrd-guest.img
>> >>     -append "console=ttyAMA0" -serial mon:stdio \
>> >>     -net none \
>> >>     -icount shift=7,rr=replay,rrfile=replay.bin
>> >>
>> >> And they both ran the same. However I kept running into:
>> >>
>> >>  [    3.542408] RPC: Registered tcp NFSv4.1 backchannel transport module.
>> >> qemu-system-arm: Missing character write event in the replay log
>> >>
>> >> This seems to be a pre-existing
>> >
>> > Does it mean that qemu-arm platform includes some serial devices that were
>> > not detected by the replay?
>>
>> It's the standard ARM platform serial port. When I read replay.txt is
>> said:
>>
>>  * Supports i386, x86_64, and ARM hardware platforms.
>>
>> Should we add some qualifications about which machine types are
>> supported? What is you ARM test case for record/replay?
>
> I tested on vexpress-a9 platform with Debian wheezy.

Thanks for that. I now have a test case that I can reproduce failures on
without needing graphics.

I've been investigating if there are any problems with the timer
processing now they have been moved into the TCG thread. The record
stage seems to work fine but I'm having difficulty figuring out why
playback freezes. It seems we get to a point where we are stuck waiting
for a suspiciously exact timer deadline:

  replay_account_executed_instructions: instructions_count reached zero
  handle_icount_deadline: deadline=471077745280
  replay_account_executed_instructions: instructions_count reached zero
  handle_icount_deadline: deadline=10000000
  [Switching to Thread 0x7fff7a7be700 (LWP 733)]

  Thread 3 "qemu-system-arm" hit Breakpoint 1, handle_icount_deadline () at 
/home/alex/lsrc/qemu/qemu.git/cpus.c:1184
  1184                    fprintf(stderr,"%s: no change to deadline=%ld for 
%ld\n",
  (gdb) c
  Continuing.
  handle_icount_deadline: no change to deadline=10000000 for 11

  Thread 3 "qemu-system-arm" hit Breakpoint 1, handle_icount_deadline () at 
/home/alex/lsrc/qemu/qemu.git/cpus.c:1184
  1184                    fprintf(stderr,"%s: no change to deadline=%ld for 
%ld\n",
  (gdb) c 10
  Will ignore next 9 crossings of breakpoint 1.  Continuing.
  handle_icount_deadline: no change to deadline=10000000 for 12
  handle_icount_deadline: no change to deadline=10000000 for 13
  handle_icount_deadline: no change to deadline=10000000 for 14
  handle_icount_deadline: no change to deadline=10000000 for 15
  handle_icount_deadline: no change to deadline=10000000 for 16
  handle_icount_deadline: no change to deadline=10000000 for 17
  handle_icount_deadline: no change to deadline=10000000 for 18
  handle_icount_deadline: no change to deadline=10000000 for 19
  handle_icount_deadline: no change to deadline=10000000 for 20
  handle_icount_deadline: no change to deadline=10000000 for 21

  (gdb) p replay_state
  $1 = {cached_clock = {1490191319270134000, 0}, current_step = 267869922, 
instructions_count = 0, data_kind = 12, has_unread_data = 1, file_offset = 0, 
block_request_id = 0}

But the timers are all enabled:

  (gdb) qemu timers
  Processing Realtime timers
    clock QEMU_CLOCK_REALTIME is enabled:true, last:-9223372036854775808
  Processing Virtual timers
    clock QEMU_CLOCK_VIRTUAL is enabled:true, last:-9223372036854775808
      timer 34297350016/1 (cb:0x555555a2e952 <ptimer_tick>)
      timer 503290000000/1000000 (cb:0x555555bd4d1d <ra_timer_handler>)
  Processing Host timers
    clock QEMU_CLOCK_HOST is enabled:true, last:1490191319270134000
  Processing Virtual RT timers
    clock QEMU_CLOCK_VIRTUAL_RT is enabled:true, last:-9223372036854775808

One area I wanted to look back at was comparing the record trace from
pre-mttcg-merge to now to see if any information was missing. However
the bin file has quite a lot of noise in it from changing fields so I
was wondering do you have any sort of dumper tool for comparing the
traces? If not is the format of the trace file specified anywhere?

I found:
  #define REPLAY_VERSION              0xe02005

but couldn't find any more than that. Is the format basically just
described by the calls to replay_put_byte?

--
Alex Bennée