On 2015-12-01 16:28, Peter Maydell wrote: > On 1 December 2015 at 16:19, Richard Henderson <r...@twiddle.net> wrote: > > If there are a lot of guest memory ops in the TB, the amount of > > code generated by tcg_out_tb_finalize could be well more than 1k. > > In the short term, increase the reservation larger than any TB > > seen in practice. > > > > Reported-by: Aurelien Jarno <aurel...@aurel32.net> > > Signed-off-by: Richard Henderson <r...@twiddle.net> > > --- > > > > Reported and discussed with Aurelien on IRC yesterday. This seems > > to be the easiest fix for the upcoming release. I will fix this > > properly (by modifying every backend's finalize routines) for 2.6. > > What would be the result of our hitting this bug? I ask because > there's a report on qemu-discuss about a qemu-i386-on-ARM-host > bug: http://lists.nongnu.org/archive/html/qemu-discuss/2015-11/msg00042.html > and the debug log (http://www.mediafire.com/download/ge611be9vbebbw7/qemu.log) > suggests we're segfaulting in translation on the TB shortly > after we (successfully) translate a TB whose final 'out' size > is 1100 and which has 64 guest writes in it. So I'm wondering > if that's actually the same bug this is fixing...
I don't think this is the same bug. The problem happens because the slow path of the softmmu load/store access is written at the end of the TB. In user mode, there is no slow path, so nothing is written at the end. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
