From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXoeo-0003XL-3u for qemu-devel@nongnu.org; Tue, 06 Dec 2011 01:37:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXoem-0002Nk-MN for qemu-devel@nongnu.org; Tue, 06 Dec 2011 01:37:38 -0500 Received: from csmailer.cs.nctu.edu.tw ([140.113.235.130]:50757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXoem-0002N8-2h for qemu-devel@nongnu.org; Tue, 06 Dec 2011 01:37:36 -0500 Date: Tue, 6 Dec 2011 14:37:24 +0800 From: =?utf-8?B?6Zmz6Z+L5Lu7?= Message-ID: <20111206063724.GA8299@cs.nctu.edu.tw> References: <20111129070343.GA3585@cs.nctu.edu.tw> <20111201090313.GB12949@cs.nctu.edu.tw> <20111201092503.GA24603@cs.nctu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Filippov Cc: Peter Maydell , qemu-devel@nongnu.org, =?utf-8?B?6Zmz6Z+L5Lu7?= Hi Max, > If your code is available online I can try it myself, the question is > where is it hosted then. > If not, then link to kernel binary and qemu exec trace would help me to= start. Personally, I really want to make our work public, but I am not the dec= ision maker. I'll push it toward open source however. =20 > >> > ?..TIMER: vector=3D0x31 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 > >> > > >> > which turns out should be function check_timer (arch/i386/kernel/i= o_apic.c). I > >> > >> If it hangs inside QEMU itself then you may try to backport commit > >> 4f61927a41a098d06e642ffdea5fc285dc3a0e6b that fixes > >> infinite loop caused by hpet interrupt probing. > > > > =E7=8B=A2 don't understand. What "it hangs inside QEMU itself" suppos= ed to mean? >=20 > QEMU doesn't execute guest code doing something for itself vs. QEMU > executes guest code in loop checking for something that doesn't > happen. >=20 > I'm talking about the first case. They may be distinguished from e.g. > guest debugger connected to QEMU's gdbstub -- in the former case it > cannot break guest execution by ^C. It turns out this is our IBTC optimization problem [1]. The IBTC should= take cross page boundary constraint into consideration as block linking does (= at least in QEMU current design) [2]. As I said before, we have two code caches in our framework: one for bas= ic block, the other for trace. I forgot to turn off trace's IBTC optimizatio= n as it doesn't consider cross page boundary right now. As a workaround, we re= turn to QEMU (dispatcher) while doing IBTC lookup, and the problem I mentioned disappeared. Sometimes I feel I am chaseing a ghost when debug our system= . ;-) [1] http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg01424.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02249.html Regards, chenwj --=20 Wei-Ren Chen (=E9=99=B3=E9=9F=8B=E4=BB=BB) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj