All of lore.kernel.org
 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 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.