From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3nev-0007Am-9N for qemu-devel@nongnu.org; Tue, 01 Dec 2015 11:20:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3ner-0006dd-Af for qemu-devel@nongnu.org; Tue, 01 Dec 2015 11:20:05 -0500 Received: from mail-qg0-x230.google.com ([2607:f8b0:400d:c04::230]:36063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3ner-0006dZ-6K for qemu-devel@nongnu.org; Tue, 01 Dec 2015 11:20:01 -0500 Received: by qgcc31 with SMTP id c31so8886991qgc.3 for ; Tue, 01 Dec 2015 08:20:00 -0800 (PST) Sender: Richard Henderson From: Richard Henderson Date: Tue, 1 Dec 2015 08:19:27 -0800 Message-Id: <1448986767-28016-1-git-send-email-rth@twiddle.net> Subject: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, aurelien@aurel32.net 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 Signed-off-by: Richard Henderson --- 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. r~ --- tcg/tcg.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tcg/tcg.c b/tcg/tcg.c index b20ed19..a163541 100644 --- a/tcg/tcg.c +++ b/tcg/tcg.c @@ -388,7 +388,11 @@ void tcg_prologue_init(TCGContext *s) /* Compute a high-water mark, at which we voluntarily flush the buffer and start over. The size here is arbitrary, significantly larger than we expect the code generation for any one opcode to require. */ - s->code_gen_highwater = s->code_gen_buffer + (total_size - 1024); + /* ??? We currently have no good estimate for, or checks in, + tcg_out_tb_finalize. If there are quite a lot of guest memory ops, + the number of out-of-line fragments could be quite high. In the + short-term, increase the highwater buffer. */ + s->code_gen_highwater = s->code_gen_buffer + (total_size - 64*1024); tcg_register_jit(s->code_gen_buffer, total_size); -- 2.5.0