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

["Alex Bennée" <alex.bennee@linaro.org>]

Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:

>> From: Alex Bennée [mailto:alex.bennee@linaro.org]
>> Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
>> >> From: Alex Bennée [mailto:alex.bennee@linaro.org]
>> >> Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
>> >> >> From: mttcg-request@listserver.greensocs.com [mailto:mttcg-
>> >> request@listserver.greensocs.com]
>> >> >>
>> >> >> The next thing on my list it to look at the icount problems and review
>> >> >> Paolo's fixes for it. However those fixes should go in a separate
>> >> >> series and I assume via Paolo's tree.
>> >> >
>> >> > Do you mean those problems that completely broke icount?
>> >>
>> >> Completely broke is a bit strong. Certainly I tested icount on my
>> >> patches but I missed the pathological failure mode that led to the
>> >> interaction between the BQL lock breaking patch and running a real
>> >> guest. It didn't break icount so much as slow down guests so much they
>> >> never got round to finishing their IRQ handling.
>> >
>> > That might look as slowing down in regular icount mode.
>> > But it becomes non-deterministic in record/replay mode.
>> > Therefore none of the recorded scenarios may be replayed.
>> >
>> > I tried the simplest command lines:
>> >
>> > qemu-system-i386.exe -icount shift=7,rr=record,rrfile=replay.bin -net
>> > none
>>
>> Running this against 2421f381dc (pre-merge of MTTCG) from the source
>> tree generates no output. My command is on Linux:
>>
>>   /x86_64-softmmu/qemu-system-x86_64 -icount shift=7,rr=record,rrfile=replay.bin -net none
>>
>> Do I need to specify the BIOS manually?
>
> No, this command line works well for me. BIOS executes and shows some messages.
> Do you have any graphical output for QEMU?

Ahh I was running remotely. OK I can now get output on the graphics
display and the described hang. I'll have a look at it.

>
>> > qemu-system-i386.exe -icount shift=7,rr=replay,rrfile=replay.bin -net none
>> >
>> > First one was used to record execution until BIOS will print its startup info.
>> > The second one is for replay, but it can replay about 200000 instructions
>> > until the problems with icount manifest itself - the execution does
>> > not proceed.
>>
>> What error message does it give? How do you know how many instructions
>> have been executed?
>
> It hangs after executing about 200000 instructions.
> I checked -d exec logs.
>
>> 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?

--
Alex Bennée