Pavel Dovgalyuk <dovga...@ispras.ru> writes: >> 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?
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
