qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: David Hildenbrand <david@redhat.com>,
	Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>,
	qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, alex.bennee@linaro.org, peterx@redhat.com
Subject: Re: [PATCH] softmmu: fix watchpoint processing in icount mode
Date: Fri, 10 Sep 2021 15:34:29 +0200	[thread overview]
Message-ID: <9bbee49c-f175-fa6e-3bda-7d117f1459b1@linaro.org> (raw)
In-Reply-To: <f103375f-9c3b-9b5b-6ef1-5437b4990c23@redhat.com>

On 9/10/21 1:15 PM, David Hildenbrand wrote:
> On 07.09.21 13:30, Pavel Dovgalyuk wrote:
>> Watchpoint processing code restores vCPU state twice:
>> in tb_check_watchpoint and in cpu_loop_exit_restore/cpu_restore_state.
>> Normally it does not affect anything, but in icount mode instruction
>> counter is incremented twice and becomes incorrect.
>> This patch eliminates unneeded CPU state restore.
>>
>> Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
>> ---
>>   softmmu/physmem.c |    5 +----
>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/softmmu/physmem.c b/softmmu/physmem.c
>> index 23e77cb771..4025dfab11 100644
>> --- a/softmmu/physmem.c
>> +++ b/softmmu/physmem.c
>> @@ -941,14 +941,11 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len,
>>                   if (wp->flags & BP_STOP_BEFORE_ACCESS) {
>>                       cpu->exception_index = EXCP_DEBUG;
>>                       mmap_unlock();
>> -                    cpu_loop_exit_restore(cpu, ra);
>> +                    cpu_loop_exit(cpu);
>>                   } else {
>>                       /* Force execution of one insn next time.  */
>>                       cpu->cflags_next_tb = 1 | curr_cflags(cpu);
>>                       mmap_unlock();
>> -                    if (ra) {
>> -                        cpu_restore_state(cpu, ra, true);
>> -                    }
>>                       cpu_loop_exit_noexc(cpu);
>>                   }
>>               }
>>
>>
> 
> I'm not an expert on that code, but it looks good to me.
> 
> Maybe we could have added a comment above the tb_check_watchpoint() call to highlight that 
> the restore will happen in there.

Hmm.  Curious.

Looking at tb_check_watchpoint, I have trouble seeing how it could be correct. 
Watchpoints can happen at any memory reference within the TB.  We should be rolling back 
to the cpu state at the memory reference (cpu_retore_state) and not the cpu state at the 
start of the TB (cpu_restore_state_from_tb).

I'm also not sure why we're invalidating tb's.  Why does watchpoint hit imply that we 
should want to ditch the TB?  If we want different behaviour from the next execution, we 
should be adjusting cflags.


r~


  reply	other threads:[~2021-09-10 13:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 11:30 [PATCH] softmmu: fix watchpoint processing in icount mode Pavel Dovgalyuk
2021-09-10 11:15 ` David Hildenbrand
2021-09-10 13:34   ` Richard Henderson [this message]
2021-09-10 13:46     ` David Hildenbrand
2021-09-10 14:41       ` Richard Henderson
2021-10-21 10:54         ` Pavel Dovgalyuk

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=9bbee49c-f175-fa6e-3bda-7d117f1459b1@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=pavel.dovgalyuk@ispras.ru \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).