Re: what are the requirements on target/ code for -icount to work correctly?

[Peter Maydell]

On Fri, 19 Jun 2020 at 12:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 19/06/20 07:46, Pavel Dovgalyuk wrote:
> > I think, that we need some efforts from target maintainers to remove all 
> > such calls.
>
> I'll take care of target/i386 (which does need one of the three
> gen_io_end calls that are left).

So why does it need it ? Why can't it just rely on "TB going to
end anyway which will clear the can_do_io flag" ?

> >> Q2: is it a requirement that after an insn which is a "known
> >> to be an I/O insn" one (like x86 in/out) and which is marked
> >> up with gen_io_start()/gen_io_end() that we also end the TB?
> >
> > It is a requirement for instructions that access virtual clock/icount
> > value (directly or not).
> >
> > There is also an assertion that can_do_io is enabled while generating an
> > interrupt. I believe, that it doesn't affect RR, but is useful for
> > deterministic icount mode.
>
> As I understand it, the definition of "I/O insn" is anything that can
> either:
>
> - affect the icount deadline (e.g. by setting or removing a
> QEMU_CLOCK_VIRTUAL timer)
>
> - interrupt the current translation block with cpu_loop_exit,
> cpu_restore_state or similar.

Right, but really what I'm interested in is what the
requirements are on translate.c code that emits one of these
insns. The exact definition of what an I/O insn seems
more straightforward (and you can always err on the safe side).

thanks
-- PMM