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
next prev parent 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).