From: Jan Kiszka <jan.kiszka@web.de>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [4799] Add instruction counter.
Date: Sun, 29 Jun 2008 15:54:52 +0200 [thread overview]
Message-ID: <4867942C.205@web.de> (raw)
In-Reply-To: <200806291416.06603.paul@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
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.
>
> I'm fairly sure limiting the length of the TB and actual instruction counting
> 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?
>
>> 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.
OK, understood.
>
>> 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).
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-06-29 13:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-29 1:03 [Qemu-devel] [4799] Add instruction counter Paul Brook
2008-06-29 4:44 ` C.W. Betts
2008-06-29 4:44 ` C.W. Betts
2008-06-29 9:58 ` Laurent Desnogues
2008-06-29 11:57 ` J. Mayer
2008-06-29 12:28 ` Paul Brook
2008-06-29 13:12 ` J. Mayer
2008-06-29 18:44 ` Stuart Brady
2008-06-29 12:37 ` [Qemu-devel] " Jan Kiszka
2008-06-29 13:16 ` Paul Brook
2008-06-29 13:54 ` Jan Kiszka [this message]
2008-06-29 14:31 ` Paul Brook
2008-07-10 23:04 ` [Qemu-devel] " Robert Reif
2008-07-11 16:42 ` Blue Swirl
2008-07-11 16:59 ` Julian Seward
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4867942C.205@web.de \
--to=jan.kiszka@web.de \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.