From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnlMs-0004na-L3 for qemu-devel@nongnu.org; Tue, 14 Mar 2017 08:15:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnlMn-0003Ig-Ow for qemu-devel@nongnu.org; Tue, 14 Mar 2017 08:15:58 -0400 Received: from mail.ispras.ru ([83.149.199.45]:52430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnlMn-0003Ga-Dp for qemu-devel@nongnu.org; Tue, 14 Mar 2017 08:15:53 -0400 From: "Pavel Dovgalyuk" References: <20170307155054.5833-1-alex.bennee@linaro.org> <001801d29bf5$dcba37d0$962ea770$@ru> <8760jdqpv2.fsf@linaro.org> In-Reply-To: <8760jdqpv2.fsf@linaro.org> Date: Tue, 14 Mar 2017 15:15:51 +0300 Message-ID: <000101d29cbc$b8df1ca0$2a9d55e0$@ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: ru Subject: Re: [Qemu-devel] [PATCH v3 00/11] MTTCG fix-ups for 2.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?'Alex_Benn=C3=A9e'?= 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 > From: Alex Benn=C3=A9e [mailto:alex.bennee@linaro.org] > Pavel Dovgalyuk 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? >=20 > 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=3D7,rr=3Drecord,rrfile=3Dreplay.bin = -net none=20 qemu-system-i386.exe -icount shift=3D7,rr=3Dreplay,rrfile=3Dreplay.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. >=20 > > Are you going to fix it? >=20 > Yes. It is certainly not intentional to regress icount and it needs to > be fixed before we release 2.9. >=20 > If you can point me towards the record/replay test cases I'll make = sure > I run them on the updated series. Pavel Dovgalyuk