qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] TCG register allocator


From: Xin Tong
Subject: Re: [Qemu-devel] TCG register allocator
Date: Wed, 25 Jan 2012 14:19:42 -0500

you understood it correctly, I saw the code just after i sent out the email.

Thanks

Xin


On Wed, Jan 25, 2012 at 2:18 PM, James Greensky <address@hidden> wrote:
> On Wed, Jan 25, 2012 at 11:10 AM, Xin Tong <address@hidden> wrote:
>> 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...
>>
>>
>> in the case you described above, which code guarantees that the
>> re-generated code is laid down in the place where the old code is.
>> This has to be do somewhere in tcg.
>>
>>
>> Xin
>>
>>
>> On Wed, Jan 25, 2012 at 1:58 PM, Xin Tong <address@hidden> wrote:
>>> 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
>>
>
> cpu_restore_state of translate-all.c.
>
> j = tcg_gen_code_search_pc(s, (uint8_t *)tc_ptr, searched_pc - tc_ptr);
>
> Maybe I don't understand your question.
>
> -Jim



reply via email to

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