From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd7Wo-0004RD-Ep for qemu-devel@nongnu.org; Fri, 18 Sep 2015 22:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zd7Wk-0007Z0-W5 for qemu-devel@nongnu.org; Fri, 18 Sep 2015 22:05:26 -0400 Received: from mail-pa0-x235.google.com ([2607:f8b0:400e:c03::235]:34878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd7Wk-0007Yw-Ph for qemu-devel@nongnu.org; Fri, 18 Sep 2015 22:05:22 -0400 Received: by pacfv12 with SMTP id fv12so66181490pac.2 for ; Fri, 18 Sep 2015 19:05:22 -0700 (PDT) Sender: Richard Henderson References: <1442552129-19242-1-git-send-email-rth@twiddle.net> <1442552129-19242-21-git-send-email-rth@twiddle.net> <55FC3949.5030902@twiddle.net> From: Richard Henderson Message-ID: <55FCC2DD.8060600@twiddle.net> Date: Fri, 18 Sep 2015 19:05:17 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 20/22] tcg: Save insn data and use it in cpu_restore_state_from_tb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= , QEMU Developers , Aurelien Jarno On 09/18/2015 03:44 PM, Peter Maydell wrote: > Well, if we're going to add a margin we need to add the worst-case margin. I guess the worst case is that deltas of the insn_data words between each insn are useless, and we need full 64-bit values to represent them -- 9 bytes for the sleb128. The deltas between sequential guest pc values will always be small -- 1 byte. The deltas between the host insns implementing guest pc values could be moderate (think move-multiple type insns performing 16 guest loads); two byte sleb128 gives us 16k range. So worst case is (1 + 9*TARGET_INSN_START_EXTRA_WORDS + 2) * TCG_MAX_INSNS. Which is 10k for mips; 6k for sparc and some others; 1.5k for alpha and all others that have no extra words. > However it occurred to me that the reason we use a margin for the codegen > is that we don't want to do a check for overrun every time we write > code to the buffer. For the datatable it seems more feasible to do > buffer length checks as we write the data. If we run out of space then > we just throw away the TB we generated (along with everything else in > the buffer) and start again. Yeah, I guess we could do that. > Would the idea with the guard page be to catch the segfault and use > that as our trigger to clear the codegen buffer and start again? Well, my idea was simply to use a guard page instead of asserts. But seeing a write to the known guard page and causing code gen to restart after flushing the buffer is an awesome idea. It does have implications for a theoretic host that can't set page permissions. But I'm not sure we support such a host even now, so discarding all of the non-mmap, non-win32 alternatives for allocating the code_gen_buffer doesn't strike me as the worst of ideas. r~