Re: Detecting Faulting Instructions From Plugins

[Aaron Lindsay via <qemu-devel@nongnu.org>]

On Feb 05 15:03, Alex Bennée wrote:
> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> > Assuming you're right that TCG is detecting "a io_readx/io_writex when
> > ->can_do_io is not true", could we detect this case when it occurs and
> > omit the instruction callbacks for the re-translation of the single
> > instruction (allow the initial callback to stand instead of trying to
> > turn back time, in a way, to prevent it)? Maybe there would have be some
> > bookkeeping in the plugin infrastructure side rather than entirely
> > omitting the callbacks when re-translating, in case that translation got
> > re-used in a case which didn't hit the same behavior and shouldn't be
> > skipped?
> 
> They are happening in two separate phases. The translation phase has no
> idea what the runtime condition will be. Once we get to runtime it's too
> late - and we trigger a new translation phase.

I believe I understand why we can't catch the initial translation. To
make sure I'm communicating well, my current understanding is that the
timeline for this case goes something like:

1) translate large block of instructions, including ldr
2) attempt to execute ldr, calling instruction callback
3) notice that access is to IO, trigger re-translation of single
   ldr instruction
4) execute block with single ldr instruction to completion, calling both
   instruction and memory callbacks

I was wondering if it would be possible to inform the re-translation in
step 3 that it's for a re-translated IO access so that it could
ultimately cause the second of the duplicate instruction callbacks to be
omitted during execution in 4.

-Aaron