qemu-devel
[Top][All Lists]
Advanced

[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: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation
Date: Tue, 1 Dec 2015 08:46:57 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 12/01/2015 08:28 AM, 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?

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]