Re: [RFC PATCH] docs/devel: add some notes on tcg-icount for developers

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 19 Jun 2020 at 14:58, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> This attempts to bring together my understanding of the requirements
>> for icount behaviour into one reference document for our developer
>> notes. It currently make one piece of conjecture which I think is true
>> that we don't need gen_io_start/end statements for non-MMIO related
>> I/O operations.
>
>> +Other I/O operations
>> +--------------------
>> +
>> +MMIO isn't the only type of operation for which we might need a
>> +correct and accurate clock. IO port instructions and accesses to
>> +system registers are the common examples here. For the clock to be
>> +accurate you end a translation block on these instructions.
>> +
>> +.. warning:: (CONJECTURE) instructions that won't get trapped in the
>> +             io_read/writex shouldn't need gen_io_start/end blocks
>> +             around them.
>
> I think this is backwards -- instructions where icount is handled
> by io_readx/io_writex are the ones that don't need to be marked
> with gen_io_start. It's the i/o instructions that don't go through
> io_readx/io_writex that need gen_io_start.

There are two types of MMIO accesses we generate:

 - normal loads/stores which if they end up accessing I/O ports
   eventually trap in io_read/writex where as they haven't been marked
   with can_do_io (via gen_io_start()) will trigger a recompile and
   exit.

 - loads and stores emitted while CF_LAST_IO && icount is in effect
   (from the above recompile) where they should be the last instruction
   in the block so the icount is correct when the do whatever they do.

What I've missed is the one other place where cpu->can_do_io is checked
which is when we read cpu_get_icount_raw_locked. In this case it is
effectively an assert that we have marked the instruction as potentially
accessing icount - although not that the gen_io_start/end was actually on
the last instruction of the block.

-- 
Alex Bennée