On Fri, 19 Jun 2020 at 13:55, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 19/06/20 14:39, Peter Maydell wrote: > > On Fri, 19 Jun 2020 at 13:37, Paolo Bonzini <pbonz...@redhat.com> wrote: > >> > >> 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. > > > > OK, so when is it valid not to end the TB after an IO instruction ? > > My initial belief was that the TB should *always* end. > > You're right, cpu_io_recompile works only for memory accesses so that > third one has to be fixed.
Cool. This is starting to sound like the right cleanup is going to be: * get rid of all the existing callsites in targets (possibly including forcing end-of-TB if the code wasn't doing that before) * add an assert that the TB really did end (easy for targets using the common-translator-loop, would need to go in per-target code for the targets that aren't [cris, lm32, microblaze, moxie, nios2, tilegx, unicore32]) * inline gen_io_end into its one remaining callsite in gen_tb_start() thanks -- PMM
