All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Bug 1647683 <1647683@bugs.launchpad.net>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	"open list:Overall" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] exec.c: simplify the breakpoint invalidation logic
Date: Tue, 06 Dec 2016 15:14:10 +0000	[thread overview]
Message-ID: <87k2bdytrx.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA8tnP5_annrApB2O_ZUXvc7HXM7+K1XOsPUVqrU6hHLeA@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On 6 December 2016 at 14:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>> A bug (1647683) was reported showing a crash when removing
>> breakpoints. The reproducer was bisected to 3359baad when tb_flush was
>> finally made thread safe. While in MTTCG the locking in
>> breakpoint_invalidate should have prevented any problems currently
>> tb_lock() is a NOP for system emulation.
>>
>> On top of it all the invalidation code was special-cased between user
>> and system emulation which was ugly. As we now have a safe tb_flush()
>> we might as well use that when breakpoints and added and removed. This
>> is the same thing we do for single-stepping and as this is during
>> debugging it isn't a major performance concern.
>>
>> Reported-by: Julian Brown
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  exec.c | 31 ++++---------------------------
>>  1 file changed, 4 insertions(+), 27 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 3d867f1..e991221 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -685,29 +685,6 @@ void cpu_exec_realizefn(CPUState *cpu, Error **errp)
>>  }
>>
>>  #if defined(CONFIG_USER_ONLY)
>> -static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
>> -{
>> -    mmap_lock();
>> -    tb_lock();
>> -    tb_invalidate_phys_page_range(pc, pc + 1, 0);
>> -    tb_unlock();
>> -    mmap_unlock();
>> -}
>> -#else
>> -static void breakpoint_invalidate(CPUState *cpu, target_ulong pc)
>> -{
>> -    MemTxAttrs attrs;
>> -    hwaddr phys = cpu_get_phys_page_attrs_debug(cpu, pc, &attrs);
>> -    int asidx = cpu_asidx_from_attrs(cpu, attrs);
>> -    if (phys != -1) {
>> -        /* Locks grabbed by tb_invalidate_phys_addr */
>> -        tb_invalidate_phys_addr(cpu->cpu_ases[asidx].as,
>> -                                phys | (pc & ~TARGET_PAGE_MASK));
>> -    }
>> -}
>> -#endif
>> -
>> -#if defined(CONFIG_USER_ONLY)
>>  void cpu_watchpoint_remove_all(CPUState *cpu, int mask)
>>
>>  {
>> @@ -839,7 +816,7 @@ int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int flags,
>>          QTAILQ_INSERT_TAIL(&cpu->breakpoints, bp, entry);
>>      }
>>
>> -    breakpoint_invalidate(cpu, pc);
>> +    tb_flush(cpu);
>>
>>      if (breakpoint) {
>>          *breakpoint = bp;
>> @@ -855,6 +832,7 @@ int cpu_breakpoint_remove(CPUState *cpu, vaddr pc, int flags)
>>      QTAILQ_FOREACH(bp, &cpu->breakpoints, entry) {
>>          if (bp->pc == pc && bp->flags == flags) {
>>              cpu_breakpoint_remove_by_ref(cpu, bp);
>> +            tb_flush(cpu);
>>              return 0;
>>          }
>>      }
>> @@ -865,9 +843,6 @@ int cpu_breakpoint_remove(CPUState *cpu, vaddr pc, int flags)
>>  void cpu_breakpoint_remove_by_ref(CPUState *cpu, CPUBreakpoint *breakpoint)
>>  {
>>      QTAILQ_REMOVE(&cpu->breakpoints, breakpoint, entry);
>> -
>> -    breakpoint_invalidate(cpu, breakpoint->pc);
>> -
>>      g_free(breakpoint);
>>  }
>>
>> @@ -881,6 +856,8 @@ void cpu_breakpoint_remove_all(CPUState *cpu, int mask)
>>              cpu_breakpoint_remove_by_ref(cpu, bp);
>>          }
>>      }
>> +
>> +    tb_flush(cpu);
>>  }
>>
>>  /* enable or disable single step mode. EXCP_DEBUG is returned by the
>
> I think this is the wrong direction. We only need to invalidate
> the TBs for the specific location the breakpoint is at.
> Even if we for the moment want to apply a big hammer of doing
> a full tb flush on breakpoint to fix this issue for this release,
> we shouldn't drop the indirection through breakpoint_invalidate(),
> because then we can't go back to invalidating just the parts we need
> easily later.

Why would we? It's not like fresh code generation is particularly slow,
especially in a debugging situation when you've just stopped the
machine.

The self-modifying-code paths make more sense to be partial in their
invalidations although I've never really measured quite how pathalogical
running a JIT inside QEMU is.

--
Alex Bennée

  reply	other threads:[~2016-12-06 15:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06 11:39 [Qemu-devel] [Bug 1647683] [NEW] Bad interaction between tb flushing & gdb stub Julian Brown
2016-12-06 11:46 ` [Qemu-devel] [Bug 1647683] " Julian Brown
2016-12-06 14:51   ` Alex Bennée
2016-12-06 12:34 ` [Qemu-devel] [Bug 1647683] [NEW] " Peter Maydell
2016-12-06 14:09   ` Peter Maydell
2016-12-06 14:51 ` [Qemu-devel] [PATCH] exec.c: simplify the breakpoint invalidation logic Alex Bennée
2016-12-06 14:54   ` Peter Maydell
2016-12-06 15:14     ` Alex Bennée [this message]
2016-12-06 16:09       ` Peter Maydell
2016-12-07 11:32     ` Paolo Bonzini
2016-12-06 15:43 ` [Qemu-devel] [Bug 1647683] Re: Bad interaction between tb flushing & gdb stub Julian Brown
2016-12-06 16:05 ` Julian Brown
2020-11-08  9:39 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2bdytrx.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=1647683@bugs.launchpad.net \
    --cc=crosthwaite.peter@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.