From: David Hildenbrand <david@redhat.com>
To: Stefan Zabka <git@zabka.it>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH v2] physmem: allow cpu_memory_rw_debug to write to MMIO devices
Date: Wed, 8 Jan 2025 21:09:59 +0100 [thread overview]
Message-ID: <4aa676ea-331f-4c8b-be1d-208804ede674@redhat.com> (raw)
In-Reply-To: <f1d67bea-7389-40c3-a304-6cec459a2f49@zabka.it>
On 08.01.25 19:35, Stefan Zabka wrote:
> On 21/12/2024 15:55, David Hildenbrand wrote:
> > Let's wait for opinions from others first.
>
> <https://www.qemu.org/docs/master/devel/submitting-a-patch.html#if-your-patch-seems-to-have-been-ignored>
> states that two weeks is a reasonable amount of time for follow-up.
>
> Should I also ping the original patch? I thought pinging the thread
> would be more appropriate, as it contains relevant information.
>
I just pushed a compiling version of the attrs.debug approach to:
https://github.com/davidhildenbrand/qemu/tree/debug_access
With two preparation patches, the relevant patch is:
From 2e85cb1724385e4b8640364415832c030e5c5e6d Mon Sep 17 00:00:00 2001
From: David Hildenbrand <david@redhat.com>
Date: Wed, 8 Jan 2025 20:58:00 +0100
Subject: [PATCH] physmem: allow cpu_memory_rw_debug to write to MMIO devices
Signed-off-by: David Hildenbrand <david@redhat.com>
---
hw/core/cpu-sysemu.c | 13 +++++++++----
include/exec/memattrs.h | 5 ++++-
include/exec/memory.h | 2 ++
system/physmem.c | 9 ++-------
4 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/hw/core/cpu-sysemu.c b/hw/core/cpu-sysemu.c
index 2a9a2a4eb5..0aa0a569e4 100644
--- a/hw/core/cpu-sysemu.c
+++ b/hw/core/cpu-sysemu.c
@@ -51,13 +51,18 @@ hwaddr cpu_get_phys_page_attrs_debug(CPUState *cpu, vaddr addr,
MemTxAttrs *attrs)
{
CPUClass *cc = CPU_GET_CLASS(cpu);
+ hwaddr paddr;
if (cc->sysemu_ops->get_phys_page_attrs_debug) {
- return cc->sysemu_ops->get_phys_page_attrs_debug(cpu, addr, attrs);
+ paddr = cc->sysemu_ops->get_phys_page_attrs_debug(cpu, addr, attrs);
+ } else {
+ /* Fallback for CPUs which don't implement the _attrs_ hook */
+ *attrs = MEMTXATTRS_UNSPECIFIED;
+ paddr = cc->sysemu_ops->get_phys_page_debug(cpu, addr);
}
- /* Fallback for CPUs which don't implement the _attrs_ hook */
- *attrs = MEMTXATTRS_UNSPECIFIED;
- return cc->sysemu_ops->get_phys_page_debug(cpu, addr);
+ /* Indicate that this is a debug access. */
+ attrs->debug = 1;
+ return paddr;
}
hwaddr cpu_get_phys_page_debug(CPUState *cpu, vaddr addr)
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
index e27c18f3dc..14e0edaa58 100644
--- a/include/exec/memattrs.h
+++ b/include/exec/memattrs.h
@@ -26,7 +26,8 @@ typedef struct MemTxAttrs {
/* Bus masters which don't specify any attributes will get this
* (via the MEMTXATTRS_UNSPECIFIED constant), so that we can
* distinguish "all attributes deliberately clear" from
- * "didn't specify" if necessary.
+ * "didn't specify" if necessary. "debug" can be set alongside
+ * "unspecified".
*/
unsigned int unspecified:1;
/*
@@ -50,6 +51,8 @@ typedef struct MemTxAttrs {
* (see MEMTX_ACCESS_ERROR).
*/
unsigned int memory:1;
+ /* Debug access that can even write to ROM. */
+ unsigned int debug:1;
/* Requester ID (for MSI for example) */
unsigned int requester_id:16;
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 3dcadcf3a2..7458082455 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -2990,6 +2990,8 @@ static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write,
MemTxAttrs attrs)
{
if (is_write) {
+ if (attrs.debug)
+ return memory_region_is_ram(mr) || memory_region_is_romd(mr);
return memory_region_is_ram(mr) && !mr->readonly &&
!mr->rom_device && !memory_region_is_ram_device(mr);
} else {
diff --git a/system/physmem.c b/system/physmem.c
index 3c2a0b0289..03d3618039 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3573,13 +3573,8 @@ int cpu_memory_rw_debug(CPUState *cpu, vaddr addr,
if (l > len)
l = len;
phys_addr += (addr & ~TARGET_PAGE_MASK);
- if (is_write) {
- res = address_space_write_rom(cpu->cpu_ases[asidx].as, phys_addr,
- attrs, buf, l);
- } else {
- res = address_space_read(cpu->cpu_ases[asidx].as, phys_addr,
- attrs, buf, l);
- }
+ res = address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, attrs, buf,
+ l, is_write);
if (res != MEMTX_OK) {
return -1;
}
--
2.47.1
You could could give that a churn if that solves your issue as well.
Let me CC more people that might have an opinion on how it should be done.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-01-08 20:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 19:49 [PATCH v2] physmem: allow cpu_memory_rw_debug to write to MMIO devices Stefan Zabka
2024-12-20 20:59 ` David Hildenbrand
2024-12-20 22:22 ` vringar
2024-12-21 14:55 ` David Hildenbrand
2025-01-08 18:35 ` Stefan Zabka
2025-01-08 20:09 ` David Hildenbrand [this message]
2025-01-10 15:44 ` Peter Maydell
2025-01-10 16:02 ` David Hildenbrand
2025-01-10 16:55 ` Alex Bennée
2025-01-10 17:06 ` Peter Maydell
2025-01-10 15:16 ` 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=4aa676ea-331f-4c8b-be1d-208804ede674@redhat.com \
--to=david@redhat.com \
--cc=git@zabka.it \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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 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.