qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] tcg: How 'CPUState::current_tb' is used?


From: Sergey Fedorov
Subject: Re: [Qemu-devel] tcg: How 'CPUState::current_tb' is used?
Date: Tue, 3 May 2016 12:56:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 03/05/16 03:02, Peter Maydell wrote:
> On 2 May 2016 at 21:18, Sergey Fedorov <address@hidden> wrote:
>> On 02/05/16 22:54, Sergey Fedorov wrote:
>>
>> Hi,
>>
>> I can't figure out how this field is used. The comment says it's "Currently
>> executing TB", but actually it's the first TB in a chain of TBs executed.
>> Grep shows the only place it is really checked is
>> tb_invalidate_phys_page_range(). That code seems to be introduced long ago
>> in:
>>
>> commit ea1c18022edd0e2c45552d6fc2da6e15a3486b33
>> Author: bellard <address@hidden>
>> Date:   Mon Jun 14 18:56:36 2004 +0000
>>
>>     fixed self modifying code in case of asynchronous interrupt
>>
>>
>> I suspect it's only related to user emulation. But I would appreciate if
>> someone could give me an idea of how this really works :)
>>
>>
>> UPD: 'CPUState::current_tb' was used in that version of QEMU by this code:
>>
>> /* mask must never be zero, except for A20 change call */
>> void cpu_interrupt(CPUState *env, int mask)
>> {
>>     TranslationBlock *tb;
>>     static int interrupt_lock;
>>
>>     env->interrupt_request |= mask;
>>     /* if the cpu is currently executing code, we must unlink it and
>>        all the potentially executing TB */
>>     tb = env->current_tb;
>>     if (tb && !testandset(&interrupt_lock)) {
>>         env->current_tb = NULL;
>>         tb_reset_jump_recursive(tb);
>>         interrupt_lock = 0;
>>     }
>> }
>>
>>
>> cpu_interrupt() has changed almost completely since that time. I'm wondering
>> if checking 'cpu->current_tb' by this code in
>> tb_invalidate_phys_page_range() still makes any sense:
>>
>> if (cpu->interrupt_request && cpu->current_tb) {
>>     cpu_interrupt(cpu, cpu->interrupt_request);
>> }
>>
>>
>> BTW, I'm not sure about the purpose of this piece of code either :)
> I think it's now obsolete. When cpu_interrupt() worked
> by unlinking the TB being executed and all the ones that it
> chained to, then (as you see in the code you quote) cpu_interrupt()
> only did actual work if env->current_tb was set. The code in
> tb_invalidate_phys_page_range() doesn't want that work to happen
> while it's in tb_phys_invalidate() [it would have tried to
> modify the TB graph in the signal handler in the middle of
> tb_phys_invalidate also modifying the graph and corrupted it],
> so it sets cpu->current_tb to NULL to suppress this. However
> that then meant that if we had an asynchronous interrupt
> (ie executed cpu_interrupt() in a signal handler) it would
> have done nothing, so the tb_invalidate_phys_page_range()
> code now has to say "if we did get an interrupt, do the work
> now" after it restores the current_tb pointer.
>
> Since cpu_interrupt() no longer does complicated TB graph
> modification it now does it unconditionally, so the work
> done by tb_invalidate_phys_page_range() to clear cpu->current_tb
> is unnecessary and so is the extra call to cpu_interrupt()
> afterwards.
>
> So I think the current_tb field can be deleted, and so
> can the code fragments
>             /* we need to do that to handle the case where a signal
>                occurs while doing tb_phys_invalidate() */
>             saved_tb = NULL;
>             if (cpu != NULL) {
>                 saved_tb = cpu->current_tb;
>                 cpu->current_tb = NULL;
>             }
>
> and
>             if (cpu != NULL) {
>                 cpu->current_tb = saved_tb;
>                 if (cpu->interrupt_request && cpu->current_tb) {
>                     cpu_interrupt(cpu, cpu->interrupt_request);
>                 }
>             }
>
> because with our current code a signal and resulting
> call to cpu_interrupt() is perfectly safe even if it
> happens while we're executing tb_phys_invalidate().

Thank you for the detailed explanation. Now, in the morning, I can see
it :) I'll prepare a patch for this.

Kind regards,
Sergey



reply via email to

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