Re: [Qemu-devel] [PATCH v6 00/25] tcg cross-tb optimizations

["Emilio G. Cota" <cota@braap.org>]

On Wed, May 03, 2017 at 09:27:54 -0700, Richard Henderson wrote:
> On 05/03/2017 08:51 AM, Emilio G. Cota wrote:
> >On Tue, May 02, 2017 at 20:36:52 -0700, Richard Henderson wrote:
> >>On 05/02/2017 12:22 PM, Richard Henderson wrote:
> >>>Changes since v5:
> >>...
> >>>   * Alpha frontend patch rewritten; the former patch appears to
> >>>     drop clock interrupts, not exiting the kernel's idle loop.
> >>>     I never *really* figured out why, since both patches seem
> >>>     to annotate the same TBs in the same way.
> >>
> >>There's definitely something odd going on.
> >>
> >>With a rebuild from scratch, the same symptoms have re-appeared for Alpha.
> >>So it really had nothing to do with the original patch.  I'm at a bit of a
> >>loss...
> >
> >I can reliably reproduce a freeze upon booting.
> 
> Oh good.  Sort of.  The oddly non-reproducible nature of this for me has
> been disconcerting.

I'm booting this image:
  https://gmplib.org/~tege/qemu/images/alpha/disk.img.xz
with this kernel:
  https://gmplib.org/~tege/qemu/images/alpha/vmlinux
invoking with:
  $ qemu-system-alpha -m 512 -drive file=disk.img,media=disk,format=raw,index=0 \
	-kernel vmlinux -append "root=/dev/sda2" [-accel accel=tcg,thread=multi]
I got the above from https://gmplib.org/~tege/qemu.html

I can reproduce reliably with either thread=single or =multi. When booting,
it stops for a few seconds  at "Key type dns_resolver registered"; then it
prints a few more lines to then stop for a while at
"sd 0:0:0:0: [sda] Attached SCSI disk". If I wait long enough, it
does boot. However, without the chaining patch it boots in a few seconds.

> >Interestingly, if I leave the lookup_and_goto_ptr above (s/#if 0/#if 1/), but
> >change the lookup_ptr helper to bypass tb_jmp_cache and directly check the
> >htable, it boots OK.
> 
> Now that *is* odd.  However ...
> 
> >Could it be that we're forgetting to clear (or set) tb_jmp_cache somewhere?
> 
> ... even that should not affect the setting (or clearing) of
> cpu->icount_decr.u16.high.  Which should have been set by
> tcg_handle_interrupt.  We should have exited the chain of TBs at some point.
> 
> Which to me means there's some deeper issue.  I.e. the only reason it's been
> working to date so far is that previously we never put together chains of
> any great length.

Yes, this is my hypothesis as well.

		E.