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

["Pavel Dovgalyuk" <dovgaluk@ispras.ru>]

> 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 

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.

> That certainly seems to be fixed by Paolo's patches.
> 
> > Are you going to fix it?
> 
> Yes. It is certainly not intentional to regress icount and it needs to
> be fixed before we release 2.9.
> 
> If you can point me towards the record/replay test cases I'll make sure
> I run them on the updated series.


Pavel Dovgalyuk