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

[Paolo Bonzini <pbonzini@redhat.com>]

On 19/06/20 14:18, Peter Maydell wrote:
> 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" ?

Because the TB is not always going to end in that case that is left.

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

I would be interested in a precise definition of that as well (I've not
really done any icount work on the translation side).

Paolo

> The exact definition of what an I/O insn seems
> more straightforward (and you can always err on the safe side).
> 
> thanks
> -- PMM
>