qemu-devel.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: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Alexandre Iooss" <erdnaxe@crans.org>,
	"Mahmoud Mandour" <ma.mandourr@gmail.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"John Snow" <jsnow@redhat.com>, "Cleber Rosa" <crosa@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Michael Rolnik" <mrolnik@gmail.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Brian Cain" <bcain@quicinc.com>,
	"Song Gao" <gaosong@loongson.cn>,
	"Xiaojuan Yang" <yangxiaojuan@loongson.cn>,
	"Laurent Vivier" <laurent@vivier.eu>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
	"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
	"Chris Wulff" <crwulff@gmail.com>, "Marek Vasut" <marex@denx.de>,
	"Stafford Horne" <shorne@gmail.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Cédric Le Goater" <clg@kaod.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Greg Kurz" <groug@kaod.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Weiwei Li" <liweiwei@iscas.ac.cn>,
	"Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"David Hildenbrand" <david@redhat.com>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	qemu-devel@nongnu.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	qemu-riscv@nongnu.org, qemu-s390x@nongnu.org
Subject: Re: [RFC PATCH 21/24] plugins: Allow to read registers
Date: Mon, 14 Aug 2023 16:05:16 +0100	[thread overview]
Message-ID: <87y1idpseh.fsf@linaro.org> (raw)
In-Reply-To: <20230731084354.115015-22-akihiko.odaki@daynix.com>


Akihiko Odaki <akihiko.odaki@daynix.com> writes:

> It is based on GDB protocol to ensure interface stability.

See comments bellow.

> The timing of the vcpu init hook is also changed so that the hook will
> get called after GDB features are initialized.

This might be worth splitting to a separate patch for cleaner bisecting.

>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
>  include/qemu/qemu-plugin.h   | 65 ++++++++++++++++++++++++++++++++++--
>  cpu.c                        | 11 ------
>  hw/core/cpu-common.c         | 10 ++++++
>  plugins/api.c                | 40 ++++++++++++++++++++++
>  plugins/qemu-plugins.symbols |  2 ++
>  5 files changed, 114 insertions(+), 14 deletions(-)
>
> diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> index 50a9957279..214b12bfd6 100644
> --- a/include/qemu/qemu-plugin.h
> +++ b/include/qemu/qemu-plugin.h
> @@ -11,6 +11,7 @@
>  #ifndef QEMU_QEMU_PLUGIN_H
>  #define QEMU_QEMU_PLUGIN_H
>  
> +#include <glib.h>
>  #include <inttypes.h>
>  #include <stdbool.h>
>  #include <stddef.h>
> @@ -51,7 +52,7 @@ typedef uint64_t qemu_plugin_id_t;
>  
>  extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
>  
> -#define QEMU_PLUGIN_VERSION 1
> +#define QEMU_PLUGIN_VERSION 2
>  
>  /**
>   * struct qemu_info_t - system information for plugins
> @@ -218,8 +219,8 @@ struct qemu_plugin_insn;
>   * @QEMU_PLUGIN_CB_R_REGS: callback reads the CPU's regs
>   * @QEMU_PLUGIN_CB_RW_REGS: callback reads and writes the CPU's regs
>   *
> - * Note: currently unused, plugins cannot read or change system
> - * register state.
> + * Note: currently QEMU_PLUGIN_CB_RW_REGS is unused, plugins cannot change
> + * system register state.
>   */
>  enum qemu_plugin_cb_flags {
>      QEMU_PLUGIN_CB_NO_REGS,
> @@ -664,4 +665,62 @@ uint64_t qemu_plugin_end_code(void);
>   */
>  uint64_t qemu_plugin_entry_code(void);
>  
> +/**
> + * struct qemu_plugin_register_file_t - register information
> + *
> + * This structure identifies registers. The identifiers included in this
> + * structure are identical with names used in GDB's standard target features
> + * with some extensions. For details, see:
> + *
> https://sourceware.org/gdb/onlinedocs/gdb/Standard-Target-Features.html

I'm not super keen on baking GDB-isms into the plugin register
interface.

> + *
> + * A register is uniquely identified with the combination of a feature name
> + * and a register name or a register number. It is recommended to derive
> + * register numbers from feature names and register names each time a new vcpu
> + * starts.

Do you have examples of clashing register names from different feature
sets? 

> + *
> + * To derive the register number from a feature name and a register name,
> + * first look up qemu_plugin_register_file_t with the feature name, and then
> + * look up the register name in its @regs. The sum of the @base_reg and the
> + * index in the @reg is the register number.
> + *
> + * Note that @regs may have holes; some elements of @regs may be NULL.
> + */
> +typedef struct qemu_plugin_register_file_t {
> +    /** @name: feature name */
> +    const char *name;
> +    /** @regs: register names */
> +    const char * const *regs;
> +    /** @base_reg: the base identified number */
> +    int base_reg;
> +    /** @num_regs: the number of elements in @regs */
> +    int num_regs;
> +} qemu_plugin_register_file_t;
> +
> +/**
> + * qemu_plugin_get_register_files() - returns register information
> + *
> + * @vcpu_index: the index of the vcpu context
> + * @size: the pointer to the variable to hold the number of returned elements
> + *
> + * Returns an array of qemu_plugin_register_file_t. The user should g_free()
> + * the array once no longer needed.
> + */
> +qemu_plugin_register_file_t *
> +qemu_plugin_get_register_files(unsigned int vcpu_index, int *size);

I think I'd rather have a simpler interface that returns an anonymous
handle to the plugin. For example:

  struct qemu_plugin_register;
  struct qemu_plugin_register qemu_plugin_find_register(const char *name);

> +
> +/**
> + * qemu_plugin_read_register() - read register
> + *
> + * @buf: the byte array to append the read register content to.
> + * @reg: the register identifier determined with
> + *       qemu_plugin_get_register_files().
> + *
> + * This function is only available in a context that register read access is
> + * explicitly requested.
> + *
> + * Returns the size of the read register. The content of @buf is in target byte
> + * order.
> + */
> +int qemu_plugin_read_register(GByteArray *buf, int reg);

and this then becomes:

  int qemu_plugin_read_register(GByteArray *buf, struct qemu_plugin_register);

in practice these can become anonymous pointers which hide the
implementation details from the plugin itself. Then the details of
mapping the register to a gdb regnum can be kept in the plugin code
keeping us free to further re-factor the code as we go.

The plugin code works quite hard to try and avoid leaking implementation
details to plugins so as not to tie QEMU's hands in re-factoring. While
the interface provided is technically GDB's, not QEMUs I don't think its
a particularly nice one to expose.

<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  reply	other threads:[~2023-08-14 15:16 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31  8:43 [RFC PATCH 00/24] plugins: Allow to read registers Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 01/24] contrib/plugins: Use GRWLock in execlog Akihiko Odaki
2023-08-14 10:48   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 02/24] gdbstub: Introduce GDBFeature structure Akihiko Odaki
2023-07-31 13:34   ` Philippe Mathieu-Daudé
2023-07-31 13:51   ` Philippe Mathieu-Daudé
2023-08-14 11:33   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 03/24] gdbstub: Add num_regs member to GDBFeature Akihiko Odaki
2023-07-31 13:35   ` Philippe Mathieu-Daudé
2023-08-14 11:44   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 04/24] gdbstub: Introduce gdb_find_static_feature() Akihiko Odaki
2023-07-31 13:52   ` Philippe Mathieu-Daudé
2023-08-14 11:56   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 05/24] target/arm: Move the reference to arm-core.xml Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 06/24] hw/core/cpu: Replace gdb_core_xml_file with gdb_core_feature Akihiko Odaki
2023-07-31 13:27   ` Philippe Mathieu-Daudé
2023-07-31 13:37     ` Akihiko Odaki
2023-08-14 11:59   ` Alex Bennée
2023-08-16 13:47     ` Akihiko Odaki
2023-08-16 15:00       ` Alex Bennée
2023-08-16 15:10         ` Akihiko Odaki
2023-08-14 13:19   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 07/24] target/arm: Use GDBFeature for dynamic XML Akihiko Odaki
2023-07-31 13:44   ` Philippe Mathieu-Daudé
2023-07-31 14:00     ` Akihiko Odaki
2023-08-14 13:01   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 08/24] target/ppc: " Akihiko Odaki
2023-07-31 13:45   ` Philippe Mathieu-Daudé
2023-07-31  8:43 ` [RFC PATCH 09/24] target/riscv: " Akihiko Odaki
2023-07-31 13:46   ` Philippe Mathieu-Daudé
2023-07-31  8:43 ` [RFC PATCH 10/24] gdbstub: Use GDBFeature for gdb_register_coprocessor Akihiko Odaki
2023-08-14 13:13   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 11/24] gdbstub: Use GDBFeature for GDBRegisterState Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 12/24] gdbstub: Simplify XML lookup Akihiko Odaki
2023-08-14 13:27   ` Alex Bennée
2023-08-16 13:51     ` Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 13/24] hw/core/cpu: Remove gdb_get_dynamic_xml member Akihiko Odaki
2023-08-14 13:29   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 14/24] gdbstub: Add members to identify registers to GDBFeature Akihiko Odaki
2023-08-14 13:30   ` Alex Bennée
2023-07-31  8:43 ` [RFC PATCH 15/24] target/arm: Fill new members of GDBFeature Akihiko Odaki
2023-08-14 14:56   ` Alex Bennée
2023-08-16 14:23     ` Akihiko Odaki
2023-08-16 15:03       ` Alex Bennée
2023-08-16 15:11         ` Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 16/24] target/ppc: " Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 17/24] target/riscv: " Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 18/24] hw/core/cpu: Add a parameter to gdb_read_register/gdb_write_register Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 19/24] gdbstub: Hide gdb_has_xml Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 20/24] gdbstub: Expose functions to read registers Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 21/24] plugins: Allow " Akihiko Odaki
2023-08-14 15:05   ` Alex Bennée [this message]
2023-08-16 14:38     ` Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 22/24] contrib/plugins: Allow to log registers Akihiko Odaki
2023-08-14 15:21   ` Alex Bennée
2023-08-16 14:59     ` Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 23/24] plugins: Support C++ Akihiko Odaki
2023-07-31  8:43 ` [RFC PATCH 24/24] contrib/plugins: Add cc plugin Akihiko Odaki
2023-08-14 15:23   ` Alex Bennée
2023-08-16 15:04     ` Akihiko Odaki
2023-08-14 15:27 ` [RFC PATCH 00/24] plugins: Allow to read registers 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=87y1idpseh.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=alistair.francis@wdc.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=bcain@quicinc.com \
    --cc=berrange@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=clg@kaod.org \
    --cc=crosa@redhat.com \
    --cc=crwulff@gmail.com \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=erdnaxe@crans.org \
    --cc=gaosong@loongson.cn \
    --cc=groug@kaod.org \
    --cc=iii@linux.ibm.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jsnow@redhat.com \
    --cc=kbastian@mail.uni-paderborn.de \
    --cc=laurent@vivier.eu \
    --cc=liweiwei@iscas.ac.cn \
    --cc=ma.mandourr@gmail.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marex@denx.de \
    --cc=mark.cave-ayland@ilande.co.uk \
    --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=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=shorne@gmail.com \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.com \
    --cc=yangxiaojuan@loongson.cn \
    --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 NNTP newsgroup(s).