> From: Alex Bennée [mailto:alex.ben...@linaro.org] > Pavel Dovgalyuk <dovga...@ispras.ru> writes: > >> From: Alex Bennée [mailto:alex.ben...@linaro.org] > >> Pavel Dovgalyuk <dovga...@ispras.ru> writes: > >> >> From: mttcg-requ...@listserver.greensocs.com [mailto:mttcg- > >> requ...@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? > > 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? Pavel Dovgalyuk
