From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCwlI-0000Gl-F2 for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:16:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCwlG-0000GF-UK for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:16:12 -0400 Received: from [199.232.76.173] (port=60875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCwlG-0000GA-LO for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:16:10 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:41397) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KCwlG-0002E0-I5 for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:16:10 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [4799] Add instruction counter. Date: Sun, 29 Jun 2008 14:16:06 +0100 References: <4867820F.8070002@web.de> In-Reply-To: <4867820F.8070002@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806291416.06603.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka > On the first glance this function looked like it could serve as an > alternative to SSTEP_INTERNAL and provide the required roll-back on > watchpoint hit. But looking closer I realized that icount_decr is only > maintained if use_icount is set. I'm fairly sure limiting the length of the TB and actual instruction counting are largely independent. IIUC you only need the former. > I do not yet get why you were forced to go a different path for > cpu_io_recompile, ie. rebuilding and (re-executing?) the whole TB up to > the instruction that caused the IO access instead of just regenerating a > single-insn TB for that purpose. Is it more efficient? Generating a single insn IO TB is a good idea for resolving the current fault. This is what the comment at the end of cpu_io_recompile is referring to. Regenerating a truncated version of the original version of the TB is important for subsequent execution of that block. MMIO accesses occur frequently in loops when the guest is checking status bits or accessing a FIFO. Recompiling the TB means that subsequent accesses complete with minimal overhead. If we didn't recompile then every access would incur a (very expensive) trap+unwind+singlestep. The type of access can't be determined statically (it's a property of the address being accesses, not the instruction itself). However I'd expect that most accesses always access wither RAM or MMIO spaces in practice, so recompiling when we see an IO access is a reasonable compromise. > But if use_icount is off by default, I guess this doesn't come for free > either... See above. cpu_io_recompile is used to get precise delivery of interrupts. This is required for but not dependent on having deterministic timing (i.e. use_icount). Paul