From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Perry Hung <perry@mosi.io>,
qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Cc: pbonzini@redhat.com, peterx@redhat.com, david@redhat.com,
Andreas Rasmusson <andreas.rasmusson@gmail.com>
Subject: Re: [PATCH] physmem: allow debug writes to MMIO regions
Date: Wed, 15 May 2024 14:49:44 +0200 [thread overview]
Message-ID: <42e47d17-1d49-43e8-abd6-76abdcb159dc@linaro.org> (raw)
In-Reply-To: <20240513233305.2975295-1-perry@mosi.io>
Hi Perry,
On 14/5/24 01:33, Perry Hung wrote:
> Writes from GDB to memory-mapped IO regions are currently silently
> dropped. cpu_memory_rw_debug() calls address_space_write_rom(), which
> calls address_space_write_rom_internal(), which ignores all non-ram/rom
> regions.
>
> Add a check for MMIO regions and direct those to address_space_rw()
> instead.
>
Reported-by: Andreas Rasmusson <andreas.rasmusson@gmail.com>
BugLink: https://bugs.launchpad.net/qemu/+bug/1625216
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/213
> Signed-off-by: Perry Hung <perry@mosi.io>
> ---
> system/physmem.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/system/physmem.c b/system/physmem.c
> index 342b7a8fd4..013cdd2ab1 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -3508,7 +3508,10 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
> if (l > len)
> l = len;
> phys_addr += (addr & ~TARGET_PAGE_MASK);
> - if (is_write) {
> + if (cpu_physical_memory_is_io(phys_addr)) {
> + res = address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, attrs,
> + buf, l, is_write);
> + } else if (is_write) {
> res = address_space_write_rom(cpu->cpu_ases[asidx].as, phys_addr,
> attrs, buf, l);
> } else {
I wonder if we shouldn't be safer with a preliminary patch
adding a 'can_do_io' boolean argument to cpu_memory_rw_debug()
(updating the call sites), then this patch would become:
if (can_do_io && cpu_physical_memory_is_io(phys_addr)) {
One of my worries for example is if someone accidently insert
a breakpoint at a I/O address, the device might change its
state and return MEMTX_OK which is confusing.
Regards,
Phil.
next prev parent reply other threads:[~2024-05-15 12:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 23:33 [PATCH] physmem: allow debug writes to MMIO regions Perry Hung
2024-05-15 12:49 ` Philippe Mathieu-Daudé [this message]
2024-05-20 17:22 ` Peter Maydell
2024-05-20 18:48 ` Perry Hung
2024-05-31 13:00 ` 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=42e47d17-1d49-43e8-abd6-76abdcb159dc@linaro.org \
--to=philmd@linaro.org \
--cc=andreas.rasmusson@gmail.com \
--cc=david@redhat.com \
--cc=pbonzini@redhat.com \
--cc=perry@mosi.io \
--cc=peter.maydell@linaro.org \
--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).