qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Claudio Fontana <cfontana@suse.de>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Riku Voipio" <riku.voipio@iki.fi>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [RFC PATCH 6/6] softmmu: Restrict watchpoint handlers to TCG accelerator
Date: Mon, 15 Feb 2021 11:42:58 +0100	[thread overview]
Message-ID: <e4defdd6-a9f9-94bd-1139-a5c6b949b2e4@suse.de> (raw)
In-Reply-To: <40633db0-62ac-4a17-cc20-0cab61bb5df6@amsat.org>

On 1/18/21 10:36 AM, Philippe Mathieu-Daudé wrote:
> On 1/18/21 10:10 AM, Claudio Fontana wrote:
>> On 1/17/21 5:48 PM, Philippe Mathieu-Daudé wrote:
>>> Watchpoint funtions use cpu_restore_state() which is only
>>> available when TCG accelerator is built. Restrict them
>>> to TCG.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>
>> I am doing some of this in my series, and I did not notice that
>> cpu_watchpoint_insert was also TCG only.
>>
>> Probably we should merge this somehow.
>>
>> I thought it was used by gdbstub.c as well, passing flags BP_GDB .
> 
> BP_MEM_ACCESS for watchpoint.
> 
>> I noticed that gdbstub does something else entirely for kvm_enabled(), ie, kvm_insert_breakpoint,
>> but what about the other accels, it seems that the code flows to the cpu_breakpoint_insert and watchpoint_insert..?
>>
>> should cpu_breakpoint_insert have the same fate then?
>>
>> And is this really all TCG specific?
>>
>> From gdbstub.c:1020:
>>
>> static int gdb_breakpoint_insert(int type, target_ulong addr, target_ulong len)
>> {
>>     CPUState *cpu;
>>     int err = 0;
>>
>>     if (kvm_enabled()) {
>>         return kvm_insert_breakpoint(gdbserver_state.c_cpu, addr, len, type);
> 
> Doh I missed that. I remember Peter and Richard explained it once
> but I forgot and couldn't find on the list, maybe it was on IRC.
> 
> See i.e. in target/arm/kvm64.c:
> 
>  312 int kvm_arch_insert_hw_breakpoint(target_ulong addr,
>  313                                   target_ulong len, int type)
>  314 {
>  315     switch (type) {
>  316     case GDB_BREAKPOINT_HW:
>  317         return insert_hw_breakpoint(addr);
>  318         break;
>  319     case GDB_WATCHPOINT_READ:
>  320     case GDB_WATCHPOINT_WRITE:
>  321     case GDB_WATCHPOINT_ACCESS:
>  322         return insert_hw_watchpoint(addr, len, type);
>  323     default:
>  324         return -ENOSYS;
>  325     }
>  326 }
> 
>>
>>> ---
>>> RFC because we could keep that code by adding an empty
>>>     stub for cpu_restore_state(), but it is unclear as
>>>     the function is named generically.
>>> ---
>>>  include/hw/core/cpu.h | 4 ++--
>>>  softmmu/physmem.c     | 4 ++++
>>>  2 files changed, 6 insertions(+), 2 deletions(-)
> 

Hello Philippe,

I have reached this issue again when working on the ARM part of the cleanup,
did we reach a conclusion on whether cpu_watchpoint_insert is TCG-specific or not,

and more in general about breakpoints and watchpoints?

The way I encountered this issue now is during the KVM/TCG split in target/arm.

there are calls in target/arm/cpu.c and machine.c of the kind:

hw_breakpoint_update_all()
hw_watchpoint_update_all()

is this all TCG-specific,

including also hw_watchpoint_update(), hw_breakpoint_update() ?

kvm64.c seems to have its own handling of breakpoints, including arrays:

GArray *hw_breakpoints, *hw_watchpoints;

while the TCG stuff relies on cpu->watchpoints in softmmu/physmem.c:

$ gid watchpoints
include/hw/core/cpu.h:139: * address before attempting to match it against watchpoints.
include/hw/core/cpu.h:388:    QTAILQ_HEAD(, CPUWatchpoint) watchpoints;
linux-user/main.c:210:    /* Clone all break/watchpoints.
linux-user/main.c:212:       BP_CPU break/watchpoints are handled correctly on clone. */
linux-user/main.c:214:    QTAILQ_INIT(&new_cpu->watchpoints);
linux-user/main.c:218:    QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:791:    /* keep all GDB-injected watchpoints in front */
softmmu/physmem.c:793:        QTAILQ_INSERT_HEAD(&cpu->watchpoints, wp, entry);
softmmu/physmem.c:795:        QTAILQ_INSERT_TAIL(&cpu->watchpoints, wp, entry);
softmmu/physmem.c:816:    QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:829:    QTAILQ_REMOVE(&cpu->watchpoints, watchpoint, entry);
softmmu/physmem.c:836:/* Remove all matching watchpoints.  */
softmmu/physmem.c:841:    QTAILQ_FOREACH_SAFE(wp, &cpu->watchpoints, entry, next) {
softmmu/physmem.c:868:/* Return flags for watchpoints that match addr + prot.  */
softmmu/physmem.c:874:    QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:906:    QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
softmmu/physmem.c:911:                 * Don't process the watchpoints when we are
accel/tcg/cpu-exec.c:511:        QTAILQ_FOREACH(wp, &cpu->watchpoints, entry) {
accel/tcg/cpu-exec.c:822:               after-access watchpoints.  Since this request should never
hw/core/cpu.c:361:    QTAILQ_INIT(&cpu->watchpoints);


Even in i386 there is a bit of confusion still, and I think sorting out this could improve the code on i386 as well..

Thanks for any comment,

Ciao,

CLaudio










  reply	other threads:[~2021-02-15 10:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 16:48 [PATCH 0/6] accel: Restrict TCG-specific code Philippe Mathieu-Daudé
2021-01-17 16:48 ` [PATCH 1/6] accel/tcg: Make cpu_gen_init() static Philippe Mathieu-Daudé
2021-01-18  9:14   ` Claudio Fontana
2021-01-21  5:54   ` Richard Henderson
2021-01-17 16:48 ` [PATCH 2/6] accel/tcg: Restrict tb_flush_jmp_cache() from other accelerators Philippe Mathieu-Daudé
2021-01-18  9:14   ` Claudio Fontana
2021-01-21  5:55   ` Richard Henderson
2021-01-17 16:48 ` [PATCH 3/6] accel/tcg: Restrict tb_gen_code() " Philippe Mathieu-Daudé
2021-01-18  9:12   ` Claudio Fontana
2021-01-21  6:06     ` Richard Henderson
2021-03-15 13:52       ` Claudio Fontana
2021-03-15 14:48         ` Philippe Mathieu-Daudé
2021-01-17 16:48 ` [PATCH 4/6] accel/tcg: Declare missing cpu_loop_exit*() stubs Philippe Mathieu-Daudé
2021-01-18  9:02   ` Claudio Fontana
2021-01-18  9:29   ` Claudio Fontana
2021-01-18  9:39     ` Philippe Mathieu-Daudé
2021-01-18 10:03       ` Claudio Fontana
2021-02-15 12:01         ` Alex Bennée
2021-01-21  6:21   ` Richard Henderson
2021-01-17 16:48 ` [RFC PATCH 5/6] accel/tcg: Restrict cpu_io_recompile() from other accelerators Philippe Mathieu-Daudé
2021-01-18  9:04   ` Claudio Fontana
2021-01-21  6:53   ` Richard Henderson
2021-01-17 16:48 ` [RFC PATCH 6/6] softmmu: Restrict watchpoint handlers to TCG accelerator Philippe Mathieu-Daudé
2021-01-18  9:10   ` Claudio Fontana
2021-01-18  9:36     ` Philippe Mathieu-Daudé
2021-02-15 10:42       ` Claudio Fontana [this message]
2021-02-15 12:05         ` Alex Bennée
2021-01-21  6:56   ` Richard Henderson
2021-01-18  9:20 ` [PATCH 0/6] accel: Restrict TCG-specific code Claudio Fontana

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=e4defdd6-a9f9-94bd-1139-a5c6b949b2e4@suse.de \
    --to=cfontana@suse.de \
    --cc=alex.bennee@linaro.org \
    --cc=chenhuacai@kernel.org \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=riku.voipio@iki.fi \
    /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).