From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QabLs-0007dX-KJ for qemu-devel@nongnu.org; Sat, 25 Jun 2011 18:29:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QabLr-0004w9-C6 for qemu-devel@nongnu.org; Sat, 25 Jun 2011 18:29:20 -0400 Received: from mta-1.ms.rz.rwth-aachen.de ([134.130.7.72]:46549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QabLr-0004w5-3K for qemu-devel@nongnu.org; Sat, 25 Jun 2011 18:29:19 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LND002E6AGTBD70@mta-1.ms.rz.RWTH-Aachen.de> for qemu-devel@nongnu.org; Sun, 26 Jun 2011 00:29:17 +0200 (CEST) Received: from [172.23.23.166] ([unknown] [87.79.236.180]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LND00237AGTPC50@relay-auth-1.ms.rz.rwth-aachen.de> for qemu-devel@nongnu.org; Sun, 26 Jun 2011 00:29:17 +0200 (CEST) Message-id: <4E06613D.8020603@rwth-aachen.de> Date: Sun, 26 Jun 2011 00:29:17 +0200 From: "felix.matenaar@rwth-aachen" References: <4E054935.4060406@rwth-aachen.de> <4E060C98.30706@rwth-aachen.de> In-reply-to: Subject: Re: [Qemu-devel] QEMU timing requirements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 06/25/2011 10:02 PM, Mulyadi Santosa wrote: > On Sat, Jun 25, 2011 at 23:28, felix.matenaar@rwth-aachen > wrote: >> No. What I do is using gen_helper_ to compile hooks into call/ret/jmp and >> memory access. The Heuristics can then hook the events so calculation is >> done during the execution of a basic block. I thought that it could be >> possible that Qemu sets a timeout for BBL execution to prevent CPU >> monopolization by e.g. a long sequence of rep. That would make sense because >> my heuristics calculation time falls into the BBL execution time for Qemu. >> Does anyone know more about that? > perhaps your heuristics code somehow coincide with the timer alarm > (PIT, HPET etc) emulation in Qemu....and somewhere your code is not > reentrant..... > Think I found the problem. It was a bug in my code and because of some weird circumstances, backtrace and addresses seemed to be a segfault in a BBL.