All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Fedorov <serge.fdrv@gmail.com>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org
Subject: Re: [Qemu-devel] [PULL 04/26] target-*: Introduce and use cpu_breakpoint_test
Date: Tue, 13 Oct 2015 16:40:28 +0300	[thread overview]
Message-ID: <561D09CC.9010903@gmail.com> (raw)
In-Reply-To: <561C4CA4.9010506@twiddle.net>



On 13.10.2015 03:13, Richard Henderson wrote:
> On 10/10/2015 12:34 AM, Sergey Fedorov wrote:
>>> @@ -2936,6 +2927,10 @@ static inline void
>>> gen_intermediate_code_internal(AlphaCPU *cpu,
>>>           tcg_gen_insn_start(ctx.pc);
>>>           num_insns++;
>>>
>>> +        if (unlikely(cpu_breakpoint_test(cs, ctx.pc, BP_ANY))) {
>>> +            gen_excp(&ctx, EXCP_DEBUG, 0);
>>> +            break;
>>> +        }
>>
>> Actually, control logic has changed here. The old code used a break
>> statement to exit from QTAILQ_FOREACH loop and continue with instruction
>> translation thus translating at least one instruction. The break
>> statement in the new code makes exit from the translation loop itself,
>> effectively producing zero-length TB which won't get invalidated when
>> clearing the breakpoint. Seems like we should remove the break statement
>> here and in similar cases below, right?
>
> Why do you believe that a zero-length TB won't be cleared?
> The TB still has a start address, which is contained within
> a given page, which is invalidated.
>
> Some target-*/translate.c takes care to advance the PC, but I believe
> that this is only required when the breakpoint instruction *itself*
> could span a page boundary.  I.e. the TB needs to be marked to span
> two pages.  This situation can never be true for many RISC targets.
>
> We did discuss this exact situation during review of the patch set,
> though it's probably true that there are outstanding errors in some
> translators.

I see your point, but what I am actually concerned about is the
following scenario.

Lets suppose we are going to remove a breakpoint. Eventually we can get
the following function call stack:

#0  tb_invalidate_phys_page_range()
#1  tb_invalidate_phys_addr()
#2  breakpoint_invalidate()
#3  cpu_breakpoint_remove_by_ref()
...

Then, if we come across a zero-sized TB then 'tb_start' would be equal
to 'tb_end'. That is not a big deal unless 'start' is not equal to
'tb_start'. Otherwise, "!(tb_end <= start || tb_start >= end)" condition
check will fail and that TB won't get invalidated as it should be. As I
can see this is a case when we try to remove a breakpoint which is
happened to be set at the very first instruction of a TB. So we either
need to change the condition in tb_invalidate_phys_page_range() or do
the PC advancement trick during translation, no matter can instructions
cross a page boundary or not.

Best regards,
Sergey

  parent reply	other threads:[~2015-10-13 13:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07  9:43 [Qemu-devel] [PULL 00/26] Do away with TB retranslation Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 01/26] tcg: Rename debug_insn_start to insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 02/26] target-*: Unconditionally emit tcg_gen_insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 03/26] target-*: Increment num_insns immediately after tcg_gen_insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 04/26] target-*: Introduce and use cpu_breakpoint_test Richard Henderson
2015-10-09 13:34   ` Sergey Fedorov
2015-10-13  0:13     ` Richard Henderson
2015-10-13  8:13       ` Peter Maydell
2015-10-13 13:40       ` Sergey Fedorov [this message]
2015-10-13 20:44         ` Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 05/26] tcg: Allow extra data to be attached to insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 06/26] target-arm: Add condexec state " Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 07/26] target-i386: Add cc_op " Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 08/26] target-mips: Add delayed branch " Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 09/26] target-s390x: Add cc_op " Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 10/26] target-sh4: Add flags " Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 11/26] target-cris: Mirror gen_opc_pc into insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 12/26] target-sparc: Tidy gen_branch_a interface Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 13/26] target-sparc: Split out gen_branch_n Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 14/26] target-sparc: Remove gen_opc_jump_pc Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 15/26] target-sparc: Add npc state to insn_start Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 16/26] tcg: Merge cpu_gen_code into tb_gen_code Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 17/26] target-*: Drop cpu_gen_code define Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 18/26] tcg: Add TCG_MAX_INSNS Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 19/26] tcg: Pass data argument to restore_state_to_opc Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 20/26] tcg: Save insn data and use it in cpu_restore_state_from_tb Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 21/26] tcg: Remove gen_intermediate_code_pc Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 22/26] tcg: Remove tcg_gen_code_search_pc Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 23/26] tcg: Emit prologue to the beginning of code_gen_buffer Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 24/26] tcg: Allocate a guard page after code_gen_buffer Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 25/26] tcg: Check for overflow via highwater mark Richard Henderson
2015-10-07  9:43 ` [Qemu-devel] [PULL 26/26] tcg: Adjust CODE_GEN_AVG_BLOCK_SIZE Richard Henderson
2015-10-08 15:50 ` [Qemu-devel] [PULL 00/26] Do away with TB retranslation Peter Maydell

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=561D09CC.9010903@gmail.com \
    --to=serge.fdrv@gmail.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.