[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation |
Date: |
Tue, 1 Dec 2015 17:34:51 +0100 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On 2015-12-01 16:28, Peter Maydell wrote:
> On 1 December 2015 at 16:19, Richard Henderson <address@hidden> 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 <address@hidden>
> > Signed-off-by: Richard Henderson <address@hidden>
> > ---
> >
> > 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
address@hidden http://www.aurel32.net
Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation, Aurelien Jarno, 2015/12/01