On 19/06/20 14:18, Peter Maydell wrote: > On Fri, 19 Jun 2020 at 12:16, Paolo Bonzini <pbonz...@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 >
