From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org, "Song Gao" <gaosong@loongson.cn>,
qemu-s390x@nongnu.org,
"Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>,
"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Laurent Vivier" <laurent@vivier.eu>,
qemu-ppc@nongnu.org, "David Hildenbrand" <david@redhat.com>,
"Cédric Le Goater" <clg@kaod.org>,
"Ilya Leoshkevich" <iii@linux.ibm.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Alexandre Iooss" <erdnaxe@crans.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
qemu-arm@nongnu.org, qemu-riscv@nongnu.org,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Mahmoud Mandour" <ma.mandourr@gmail.com>,
"John Snow" <jsnow@redhat.com>, "Weiwei Li" <liwei1518@gmail.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Yoshinori Sato" <ysato@users.sourceforge.jp>,
"Brian Cain" <bcain@quicinc.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Michael Rolnik" <mrolnik@gmail.com>
Subject: Re: [PATCH v2 21/27] plugins: add an API to read registers
Date: Mon, 26 Feb 2024 21:22:14 +0900 [thread overview]
Message-ID: <691af6af-bc4f-45ce-b017-7a82269e9381@daynix.com> (raw)
In-Reply-To: <87y1b7eay6.fsf@draig.linaro.org>
On 2024/02/26 20:12, Alex Bennée wrote:
> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
>
>> On 2024/02/24 1:21, Alex Bennée wrote:
>>> We can only request a list of registers once the vCPU has been
>>> initialised so the user needs to use either call the get function on
>>> vCPU initialisation or during the translation phase.
>>> We don't expose the reg number to the plugin instead hiding it
>>> behind
>>> an opaque handle. As the register set is potentially different for
>>> each vCPU we store a separate set of handles for each vCPU. This will
>>> become more important if we are able to emulate more heterogeneous
>>> systems.
>>> Having an internal state within the plugins also allows us to expand
>>> the interface in future (for example providing callbacks on register
>>> change if the translator can track changes).
> <snip>
>>> +
>>> +/*
>>> + * Register handles
>>> + *
>>> + * The plugin infrastructure keeps hold of these internal data
>>> + * structures which are presented to plugins as opaque handles. They
>>> + * are local to each vCPU as there can be slight variations for each
>>> + * vCPU depending on enabled features. We track this in
>>> + * CPUPluginState.
>>> + */
>>
>> Since we do no longer coalesce registers for different classes, I need
>> to bring my old question back: Why don't you just cast register
>> numbers into pointers and use it as handles?
>
> In the interest of getting this merged before the fast approaching
> soft-freeze I shall do this for now. However once the plugin system has
> knowledge of individual registers exposed by TCG it will need to track
> internal state so will need some sort of container for that.
Indeed it's likely that we would have containers for registers, but we
don't know who would own them yet.
These containers may not be held by vCPU classes as you previously
proposed because we may support different configurations of one vCPU class.
The current proposal to allocate handles for each vCPU may not be what
we would want to do in the future either. To support SMP debugging with
gdbstub, gdbstub must know sets of vCPUs that have identical registers,
and once it does, it's better to allocate handles for each of such sets,
not each of vCPUs.
Let's figure out how we should manage containers when a need arises.
>
>> You can even just expose gdb_reg_num with the interface.
>
> As I have explained before I don't want plugins to treat the handle as
> a pure index in case they start providing numbers that aren't in the
> list provided by qemu_plugin_get_registers.
>
You can assert the given number has an associated name.
next prev parent reply other threads:[~2024-02-26 12:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 16:21 [PATCH v2 00/27] maintainer updates for 9.0 pre-PR (tests, plugin register support) Alex Bennée
2024-02-23 16:21 ` [PATCH v2 01/27] tests/tcg: update licenses to GPLv2 as intended Alex Bennée
2024-02-23 16:21 ` [PATCH v2 02/27] tests/tcg: bump TCG test timeout to 120s Alex Bennée
2024-02-23 19:17 ` Thomas Huth
2024-02-23 16:21 ` [PATCH v2 03/27] target/arm: Use GDBFeature for dynamic XML Alex Bennée
2024-02-23 16:21 ` [PATCH v2 04/27] target/ppc: " Alex Bennée
2024-02-23 16:21 ` [PATCH v2 05/27] target/riscv: " Alex Bennée
2024-02-23 16:21 ` [PATCH v2 06/27] gdbstub: Use GDBFeature for gdb_register_coprocessor Alex Bennée
2024-02-23 16:21 ` [PATCH v2 07/27] gdbstub: Use GDBFeature for GDBRegisterState Alex Bennée
2024-02-23 16:21 ` [PATCH v2 08/27] gdbstub: Change gdb_get_reg_cb and gdb_set_reg_cb Alex Bennée
2024-02-23 16:21 ` [PATCH v2 09/27] gdbstub: Simplify XML lookup Alex Bennée
2024-02-23 16:21 ` [PATCH v2 10/27] gdbstub: Infer number of core registers from XML Alex Bennée
2024-02-23 16:21 ` [PATCH v2 11/27] hw/core/cpu: Remove gdb_get_dynamic_xml member Alex Bennée
2024-02-23 16:21 ` [PATCH v2 12/27] gdbstub: Add members to identify registers to GDBFeature Alex Bennée
2024-02-23 16:21 ` [PATCH v2 13/27] plugins: remove previous n_vcpus functions from API Alex Bennée
2024-02-23 16:21 ` [PATCH v2 14/27] plugins: add qemu_plugin_num_vcpus function Alex Bennée
2024-02-23 16:21 ` [PATCH v2 15/27] plugins: fix order of init/idle/resume callback Alex Bennée
2024-02-23 16:21 ` [PATCH v2 16/27] linux-user: ensure nios2 processes queued work Alex Bennée
2024-02-23 16:21 ` [PATCH v2 17/27] cpu: call plugin init hook asynchronously Alex Bennée
2024-02-23 16:21 ` [PATCH v2 18/27] plugins: Use different helpers when reading registers Alex Bennée
2024-02-23 16:21 ` [PATCH v2 19/27] gdbstub: expose api to find registers Alex Bennée
2024-02-23 16:21 ` [PATCH v2 20/27] plugins: create CPUPluginState and migrate plugin_mask Alex Bennée
2024-02-26 7:33 ` Pierrick Bouvier
2024-02-23 16:21 ` [PATCH v2 21/27] plugins: add an API to read registers Alex Bennée
2024-02-24 8:34 ` Akihiko Odaki
2024-02-26 11:12 ` Alex Bennée
2024-02-26 12:22 ` Akihiko Odaki [this message]
2024-02-23 16:21 ` [PATCH v2 22/27] tests/tcg: expand insn test case to exercise register API Alex Bennée
2024-02-23 16:21 ` [PATCH v2 23/27] contrib/plugins: fix imatch Alex Bennée
2024-02-23 16:21 ` [PATCH v2 24/27] contrib/plugins: extend execlog to track register changes Alex Bennée
2024-02-26 7:30 ` Pierrick Bouvier
2024-02-23 16:22 ` [PATCH v2 25/27] docs/devel: lift example and plugin API sections up Alex Bennée
2024-02-23 16:22 ` [PATCH v2 26/27] docs/devel: document some plugin assumptions Alex Bennée
2024-02-23 16:22 ` [PATCH v2 27/27] docs/devel: plugins can trigger a tb flush 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=691af6af-bc4f-45ce-b017-7a82269e9381@daynix.com \
--to=akihiko.odaki@daynix.com \
--cc=alex.bennee@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=bcain@quicinc.com \
--cc=bin.meng@windriver.com \
--cc=clg@kaod.org \
--cc=crosa@redhat.com \
--cc=danielhb413@gmail.com \
--cc=david@redhat.com \
--cc=dbarboza@ventanamicro.com \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=erdnaxe@crans.org \
--cc=gaosong@loongson.cn \
--cc=iii@linux.ibm.com \
--cc=jsnow@redhat.com \
--cc=laurent@vivier.eu \
--cc=liwei1518@gmail.com \
--cc=ma.mandourr@gmail.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mrolnik@gmail.com \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=ysato@users.sourceforge.jp \
--cc=zhiwei_liu@linux.alibaba.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).