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" ? > >> 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. The exact definition of what an I/O insn seems more straightforward (and you can always err on the safe side). thanks -- PMM
