qemu-riscv.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: qemu-devel@nongnu.org,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"David Hildenbrand" <david@redhat.com>,
	"Weiwei Li" <liwei1518@gmail.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Michael Rolnik" <mrolnik@gmail.com>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	qemu-ppc@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-riscv@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Song Gao" <gaosong@loongson.cn>,
	qemu-arm@nongnu.org,
	"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
	"John Snow" <jsnow@redhat.com>, "Cédric Le Goater" <clg@kaod.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	qemu-s390x@nongnu.org, "Laurent Vivier" <laurent@vivier.eu>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Brian Cain" <bcain@quicinc.com>,
	"Mahmoud Mandour" <ma.mandourr@gmail.com>,
	"Alexandre Iooss" <erdnaxe@crans.org>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>
Subject: Re: [PATCH 18/23] plugins: add an API to read registers
Date: Fri, 23 Feb 2024 16:24:18 +0000	[thread overview]
Message-ID: <878r3b87yl.fsf@draig.linaro.org> (raw)
In-Reply-To: <87jzmv8kwx.fsf@draig.linaro.org> ("Alex Bennée"'s message of "Fri, 23 Feb 2024 11:44:30 +0000")

Alex Bennée <alex.bennee@linaro.org> writes:

> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
<snip>
>>> What about if I just key based of gdb_regnum and we accept that that
>>> might break the one heterogeneous system we model today?
>>> 
>>
>> That's the best option in my opinion. gdbstub won't work well with
>> such a system anyway, and fixing it will need something similar to
>> GHashTable. But if I would fix gdbstub for a heterogeneous system, I
>> would add a field to CPUClass instead of having a GHashTable keyed
>> with tuples of CPUClass pointers and register numbers. It should be
>> fine considering that CPUState already has gdbstub-specific fields
>> like gdb_regs.
>
> It would be nice to move all register code into CPUClass to avoid
> repeating ourselves but I suspect that is quite an invasive change for a
> later series. Currently all the CPUClass values are set on init and
> shouldn't really be changed after that otherwise we'll have to start
> messing with locking.

Peter pointed out we can see different register sets for the same
CPUClass but with different features enabled which kills that idea. I've
just sent v2 which re-factors the plugin data a little and stores a per
CPUPluginState hash table.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  reply	other threads:[~2024-02-23 16:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 16:30 [PATCH 00/23] maintainer updates for 9.0 pre-PR (tests, plugin register support) Alex Bennée
2024-02-16 16:30 ` [PATCH 01/23] tests/tcg: update licenses to GPLv2 as intended Alex Bennée
2024-02-16 16:30 ` [PATCH 02/23] target/arm: Use GDBFeature for dynamic XML Alex Bennée
2024-02-16 16:30 ` [PATCH 03/23] target/ppc: " Alex Bennée
2024-02-16 16:30 ` [PATCH 04/23] target/riscv: " Alex Bennée
2024-02-16 16:30 ` [PATCH 05/23] gdbstub: Use GDBFeature for gdb_register_coprocessor Alex Bennée
2024-02-16 16:30 ` [PATCH 06/23] gdbstub: Use GDBFeature for GDBRegisterState Alex Bennée
2024-02-16 16:30 ` [PATCH 07/23] gdbstub: Change gdb_get_reg_cb and gdb_set_reg_cb Alex Bennée
2024-02-16 16:30 ` [PATCH 08/23] gdbstub: Simplify XML lookup Alex Bennée
2024-02-16 16:30 ` [PATCH 09/23] gdbstub: Infer number of core registers from XML Alex Bennée
2024-02-16 16:30 ` [PATCH 10/23] hw/core/cpu: Remove gdb_get_dynamic_xml member Alex Bennée
2024-02-16 16:30 ` [PATCH 11/23] gdbstub: Add members to identify registers to GDBFeature Alex Bennée
2024-02-16 16:30 ` [PATCH 12/23] plugins: remove previous n_vcpus functions from API Alex Bennée
2024-02-16 16:30 ` [PATCH 13/23] plugins: add qemu_plugin_num_vcpus function Alex Bennée
2024-02-16 16:30 ` [PATCH 14/23] plugins: fix order of init/idle/resume callback Alex Bennée
2024-02-16 16:30 ` [PATCH 15/23] cpu: call plugin init hook asynchronously Alex Bennée
2024-02-16 16:30 ` [PATCH 16/23] plugins: Use different helpers when reading registers Alex Bennée
2024-02-16 16:30 ` [PATCH 17/23] gdbstub: expose api to find registers Alex Bennée
2024-02-16 16:30 ` [PATCH 18/23] plugins: add an API to read registers Alex Bennée
2024-02-17  8:01   ` Akihiko Odaki
2024-02-20 14:14     ` Alex Bennée
2024-02-21  4:45       ` Akihiko Odaki
2024-02-21 10:02         ` Alex Bennée
2024-02-21 10:11           ` Akihiko Odaki
2024-02-21 14:14             ` Alex Bennée
2024-02-22  6:37               ` Akihiko Odaki
2024-02-22 10:20                 ` Alex Bennée
2024-02-22 13:22                   ` Akihiko Odaki
2024-02-22 17:27                     ` Alex Bennée
2024-02-23 10:58                       ` Akihiko Odaki
2024-02-23 11:44                         ` Alex Bennée
2024-02-23 16:24                           ` Alex Bennée [this message]
2024-02-16 16:30 ` [PATCH 19/23] contrib/plugins: fix imatch Alex Bennée
2024-02-16 16:30 ` [PATCH 20/23] contrib/plugins: extend execlog to track register changes Alex Bennée
2024-02-17 11:36   ` Pierrick Bouvier
2024-02-16 16:30 ` [PATCH 21/23] docs/devel: lift example and plugin API sections up Alex Bennée
2024-02-16 16:30 ` [PATCH 22/23] docs/devel: document some plugin assumptions Alex Bennée
2024-02-16 16:30 ` [PATCH 23/23] 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=878r3b87yl.fsf@draig.linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=akihiko.odaki@daynix.com \
    --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).