From: Aaron Lindsay via <qemu-devel@nongnu.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org, cota@braap.org, richard.henderson@linaro.org
Subject: Re: Plugin Register Accesses
Date: Tue, 8 Dec 2020 14:49:46 -0500 [thread overview]
Message-ID: <X8/Y2suga/zfc2G/@strawberry.localdomain> (raw)
In-Reply-To: <871rg0gogo.fsf@linaro.org>
On Dec 08 17:56, Alex Bennée wrote:
> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> > On Dec 08 12:17, Alex Bennée wrote:
> >> For registers I think there needs to be some re-factoring of QEMU's
> >> internals to do it cleanly. Currently we have each front-end providing
> >> hooks to the gdbstub as well as building up their own regid and xml to
> >> be consumed by it. We probably want a architectural neutral central
> >> repository that the front ends can register their registers (sic) and
> >> helpers with. This would then provide hooks for gdbstub to cleanly
> >> generate XML as well as an interface point for the plugin infrastructure
> >> (and probably whatever the HMP uses as well).
> >
> > In a previous incarnation, I was proxying calls to the plugin API
> > directly through to gdb_read_register() in gdbstub.c and therefore using
> > gdb as the point of commonality. I'm not saying it's ideal but... it
> > works? One downside is that you have to know 'out-of-band' which integer
> > value corresponds to the register you want to query for your
> > architecture, though it hasn't been a significant issue for me.
>
> Certainly workable for a private branch but I don't want to merge
> anything like that upstream.
Sure - I was more commenting on what I've done in case it's useful than
pushing for it to be upstreamed!
> As far as I can see there are a number of
> consumers of register information:
>
> - plugins
> - gdbstub
> - monitor (info registers)
> - -d LOG_CPU logging
>
> so rather than have them all have their hooks into every front-end I can
> see a case for consolidation.
>
> For the plugin case providing an introspection helper to get a handle on
> the register makes sense and would be less painful than teachning
> plugins about gdb regids which can and do move around with new system
> registers.
>
> qemu_plugin_reg_t *handle = qemu_plugin_find_register("x2")
>
> if we document the handle as usable across calls this can be done on
> start-up. Then it would be:
>
> uint64_t val = qemu_plugin_read_register(cpu_index, handle);
I recognize this is pseudocode, but I'm wondering "out loud" if this
would need to be variable-width instead of a uint64_t to allow for wider
registers in an actual implementation.
-Aaron
next prev parent reply other threads:[~2020-12-08 21:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 21:03 Plugin Register Accesses Aaron Lindsay
2020-12-08 12:17 ` Alex Bennée
2020-12-08 14:46 ` Aaron Lindsay via
2020-12-08 17:56 ` Alex Bennée
2020-12-08 19:44 ` Aaron Lindsay via
2020-12-30 21:12 ` Aaron Lindsay via
2021-01-07 16:49 ` Alex Bennée
2021-01-07 20:45 ` Aaron Lindsay via
2020-12-08 19:49 ` Aaron Lindsay via [this message]
2020-12-08 22:34 ` Alex Bennée
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=X8/Y2suga/zfc2G/@strawberry.localdomain \
--to=qemu-devel@nongnu.org \
--cc=aaron@os.amperecomputing.com \
--cc=alex.bennee@linaro.org \
--cc=cota@braap.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 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).