From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCxMq-0005PE-Ln for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:55:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCxMo-0005Ll-UK for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:55:00 -0400 Received: from [199.232.76.173] (port=35051 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCxMo-0005LI-Mh for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:54:58 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:44089) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCxMo-0001cK-Dv for qemu-devel@nongnu.org; Sun, 29 Jun 2008 09:54:58 -0400 Message-ID: <4867942C.205@web.de> Date: Sun, 29 Jun 2008 15:54:52 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [4799] Add instruction counter. References: <4867820F.8070002@web.de> <200806291416.06603.paul@codesourcery.com> In-Reply-To: <200806291416.06603.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FCCA5F5082D9E243BD83A63" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5FCCA5F5082D9E243BD83A63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: >> 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. >=20 > I'm fairly sure limiting the length of the TB and actual instruction co= unting=20 > are largely independent. IIUC you only need the former. But to calculate the former, you need the latter again. I wonder if it wouldn't be more efficient and flexible to specify a terminating PC instead of an instruction count. Wouldn't that make cpu_io_recompile independent of icount_decr and, thus, use_icount? >=20 >> 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 t= o >> the instruction that caused the IO access instead of just regenerating= a >> single-insn TB for that purpose. Is it more efficient? >=20 > Generating a single insn IO TB is a good idea for resolving the current= fault.=20 > This is what the comment at the end of cpu_io_recompile is referring to= =2E >=20 > Regenerating a truncated version of the original version of the TB is=20 > important for subsequent execution of that block. MMIO accesses occur = > frequently in loops when the guest is checking status bits or accessing= a=20 > FIFO. Recompiling the TB means that subsequent accesses complete with = > minimal overhead. If we didn't recompile then every access would incur = a=20 > (very expensive) trap+unwind+singlestep. >=20 > The type of access can't be determined statically (it's a property of t= he=20 > address being accesses, not the instruction itself). However I'd expect= that=20 > most accesses always access wither RAM or MMIO spaces in practice, so=20 > recompiling when we see an IO access is a reasonable compromise. OK, understood. >=20 >> But if use_icount is off by default, I guess this doesn't come for fre= e >> either...=20 >=20 > See above. cpu_io_recompile is used to get precise delivery of interrup= ts.=20 > This is required for but not dependent on having deterministic timing (= i.e.=20 > use_icount). Watchpoints, specifically guest-injected ones, require deterministic exception delivery as well. So I would like to reuse existing infrastructure that already solved a similar problem. Jan --------------enig5FCCA5F5082D9E243BD83A63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhnlC8ACgkQniDOoMHTA+nXRQCeOBMXRPAbG9ak4UT7rvC43MRQ 9ZQAn0G9nTJjcJ1kexTJLWW30jzXbuZt =qfKi -----END PGP SIGNATURE----- --------------enig5FCCA5F5082D9E243BD83A63--