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

From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: "'Alex Bennée'" <alex.bennee@linaro.org>
Cc: peter.maydell@linaro.org, rth@twiddle.net, pbonzini@redhat.com,
	qemu-devel@nongnu.org, mttcg@listserver.greensocs.com,
	fred.konrad@greensocs.com, a.rigo@virtualopensystems.com,
	cota@braap.org, bobby.prani@gmail.com, nikunj@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3 00/11] MTTCG fix-ups for 2.9
Date: Thu, 16 Mar 2017 11:34:06 +0300	[thread overview]
Message-ID: <000001d29e30$138e5700$3aab0500$@ru> (raw)
In-Reply-To: <87tw6vq43b.fsf@linaro.org>

> 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?

> > 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