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

[Pavel Dovgalyuk <dovgaluk@ispras.ru>]

On 18.06.2020 20:38, Peter Maydell wrote:
> For -icount mode to work, there are requirements on the target/
> code (notably around marking up "I/O" instructions). Unfortunately
> we've never documented what these are, which makes it pretty rough
> for people writing new targets or reviewing changes to existing ones.
> Does anybody understand what they actually are?
>
> Some more specific questions on the general theme:
>
> Q1: the comment on gen_io_end() says:
> /*
>   * cpu->can_do_io is cleared automatically at the beginning of
>   * each translation block.  The cost is minimal and only paid
>   * for -icount, plus it would be very easy to forget doing it
>   * in the translator.  Therefore, backends only need to call
>   * gen_io_start.
>   */
> but in fact multiple backends *do* call gen_io_end(). When
> does a backend have to call this, and when not? Or are those
> all legacy useless calls we should delete? (If so, can we
> just get rid of this function entirely ?)

That was my refactoring patch for removing gen_io_end calls.

But in some cases I wasn't sure that translation is stopped after that. 
In such cases gen_io_end wasn't removed.

I think, that we need some efforts from target maintainers to remove all 
such calls.

> 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.

> Or is it OK to generate more insns after that one? If the former,
> is there somewhere we can assert() that this is done ?

Sounds reasonable.

> Q3: why does gen_tb_start() call gen_io_end()? This is the
> *start* of the TB so by definition we haven't started doing
> any IO yet...

This is an artifact of gen_io_end refactoring.


Pavel Dovgalyuk