qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pavel Dovgalyuk
Subject: Re: what are the requirements on target/ code for -icount to work correctly?
Date: Fri, 19 Jun 2020 08:46:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]