Re: [Qemu-devel] TCG register allocator

[Xin Tong]

I am working on extending coremu (parallel version of qemu).
Currently, the code cache in coremu is private, I am working towards
to make it shared by all cores. I think the add_tb_jump may not be
atomic.

Thanks

Xin

On Wed, Jan 25, 2012 at 11:22 AM, Peter Maydell
<address@hidden> wrote:
> On 25 January 2012 15:55, Xin Tong <address@hidden> wrote:
>> The segfault is caused by jumping to the middle of an instruction. so
>> i want to know which TB jumps here.
>
> (a) Assuming it doesn't take too long to get there, you should
> be able to get this information by turning on the debug log
> via -d whatever. If it does take too long to get to the crash,
> you can use the savevm/loadvm support to save the VM state
> at some point slightly before the crash. Then you can run
> with the debug log enabled and '-loadvm tag' to start from the
> point when you saved the VM state. [disclaimer: depending on the
> guest machine you're emulating you might be unlucky and need to
> fix save/load first, but that's a worthwhile thing anyway :-)]
>
> (b) Might not be what you're seeing, but there's a class of bug that
> can look like a jump to the middle of an instruction that happens
> when:
>  * step 1: we generate code for a TB
>  * a load or store within that TB causes an exception
>  * to get CPUState in sync with the point of the exception
>   (and in particular to translate the host PC at the exception
>   into the guest PC at that point) we call cpu_restore_state()
>  * cpu_restore_state() calls gen_intermediate_code_pc() to
>   request a retranslation of the TB with extra info to allow
>   us to do a host-PC-to-guest-PC lookup
>  * Note that gen_intermediate_code_pc() overwrites the generated
>   code that already exists in memory, and stops as soon as it
>   reaches the point of the exception. This is harmless because
>   we are just rewriting the same bytes to memory that were there
>   already, but disastrous if...
>  * ...due to a bug, gen_intermediate_code_pc() generates different
>   code to that generated back in step 1; this tends to result
>   in writing half an instruction at the point where it stops
>  * subsequent attempts to execute that TB tend to result in
>   weird crashes, often looking like an attempt to jump into
>   the middle of an instruction
>
> This is why it's critical that gen_intermediate_code()+TCG always
> deterministically generates exactly the same native code every
> time.
>
> -- PMM