From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "David Hildenbrand" <david@redhat.com>,
"Stefan Zabka" <git@zabka.it>,
qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH v2] physmem: allow cpu_memory_rw_debug to write to MMIO devices
Date: Fri, 10 Jan 2025 16:55:31 +0000 [thread overview]
Message-ID: <871pxa4ni4.fsf@draig.linaro.org> (raw)
In-Reply-To: <CAFEAcA_2CEJKFyjvbwmpt=on=GgMVamQ5hiiVt+zUr6AY3X=Xg@mail.gmail.com> (Peter Maydell's message of "Fri, 10 Jan 2025 15:44:51 +0000")
Peter Maydell <peter.maydell@linaro.org> writes:
> On Wed, 8 Jan 2025 at 20:10, David Hildenbrand <david@redhat.com> wrote:
>>
>> 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
>
> I think this approach (having a 'debug' attribute in the MemTxAttrs
> seems reasonable. I do note that if we allow this kind of access
> to write to MMIO devices then we are also permitting ELF (and other)
> image loads to write to MMIO devices where currently we ignore those.
> That means there's probably a class of guest images (of dubious
> correctness) which will start writing junk (likely zeroes) into
> device model registers; we previously would silently ignore any
> such bogus ELF sections.
>
> Q: should we suggest behaviour for device models if they see a
> 'debug = 1' transaction, e.g. "don't update your internal state
> for a debug read if you have clear-on-read or similar kinds of
> register fields" ?
What do we do for device models that want to know which CPU things are
coming from, as per:
https://gitlab.com/qemu-project/qemu/-/issues/124
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2025-01-10 16:56 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
2025-01-10 15:44 ` Peter Maydell
2025-01-10 16:02 ` David Hildenbrand
2025-01-10 16:55 ` Alex Bennée [this message]
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=871pxa4ni4.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=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.