From: Richard Henderson <rth@twiddle.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation
Date: Tue, 1 Dec 2015 08:46:57 -0800 [thread overview]
Message-ID: <565DCF01.4040305@twiddle.net> (raw)
In-Reply-To: <CAFEAcA92UH3H8qrm_Re6qN94WvGML18K+c=CV8DvPHH1FSy31g@mail.gmail.com>
On 12/01/2015 08:28 AM, Peter Maydell wrote:
> On 1 December 2015 at 16:19, Richard Henderson <rth@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 <aurelien@aurel32.net>
>> Signed-off-by: Richard Henderson <rth@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?
A segfault, writing to the guard page for the code_gen buffer.
> 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...
It's plausible.
The maximum 32-bit memory op for arm requires 9 insns in the slow path. Times
64 that's 2304 bytes, which exceeds the current highwater buffer space.
The new 64k buffer allows for 1820 (arm backend) writes before exceeding the
highwater buffer. Which is significantly more than TCG_MAX_INSNS (512), though
not even close to OPC_MAX_SIZE (170240), which would require > 6MB in highwater
space.
r~
next prev parent reply other threads:[~2015-12-01 16:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 16:19 [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation Richard Henderson
2015-12-01 16:28 ` Peter Maydell
2015-12-01 16:34 ` Aurelien Jarno
2015-12-01 16:40 ` Aurelien Jarno
2015-12-01 23:06 ` Richard Henderson
2015-12-01 23:20 ` Peter Maydell
2015-12-01 16:46 ` Richard Henderson [this message]
2015-12-01 16:32 ` Aurelien Jarno
2015-12-02 18:36 ` Richard Henderson
2015-12-03 12:19 ` Aurelien Jarno
2015-12-04 8:36 ` Aurelien Jarno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=565DCF01.4040305@twiddle.net \
--to=rth@twiddle.net \
--cc=aurelien@aurel32.net \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.