qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] throwing away translated code on CPU reset


From: Peter Maydell
Subject: Re: [Qemu-devel] throwing away translated code on CPU reset
Date: Fri, 13 Jan 2012 09:08:24 +0000

On 13 January 2012 07:55, 陳韋任 <address@hidden> wrote:
> On Thu, Jan 12, 2012 at 02:00:38PM +0000, Peter Maydell wrote:
>> When doing TCG code translation, the target-foo translate.c
>> code is allowed to bake assumptions into the generated code from
>> the current values of various fields in the CPUState. This then
>> imposes the requirement that if the field is changed then tb_flush
>> must be called to throw away the now-incorrect generated code.
>>
>> However, cpu_reset() changes (unsurprisingly) lots of fields in
>> the CPUState, but it doesn't call tb_flush()...
>
>  I dig what tlb_flush does further and think maybe we don't need to call 
> tb_flush
> when tlb_flush is called.
>
>  First, look at tlb_flush (exec.c). It clears env's tb_jmp_cache which use GHA
> as an index to search if there is a translated code. Since tb_jmp_cache is 
> reset
> now, QEMU is forced to call tb_find_slow which uses GPA as the index.
>
>  In tb_find_slow's for loop, it compares hit TranslationBlock's various fields
> with current values. To be more specific,
>
> static TranslationBlock *tb_find_slow(...) {
>
>    for(;;) {
>        tb = *ptb1;
>        if (!tb)
>            goto not_found;
>        if (tb->pc == pc &&                    <--- Here
>            tb->page_addr[0] == phys_page1 &&
>            tb->cs_base == cs_base &&
>            tb->flags == flags) {
>        }
>   }
> }
>
>  What do you think?

This is true, but the translated code may have assumptions about
fields which are not encoded in tb_flags, if it is handling those
fields with the "tb_flush if field changes" strategy (eg on ARM
env->teecr and others).

-- PMM



reply via email to

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