Re: [Qemu-devel] [PATCH v2 20/22] tcg: Save insn data and use it in cpu_restore_state_from_tb

[Richard Henderson <rth@twiddle.net>]

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~