[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 21/27] plugins: add an API to read registers

From: Akihiko Odaki
Subject: Re: [PATCH v2 21/27] plugins: add an API to read registers
Date: Mon, 26 Feb 2024 21:22:14 +0900
User-agent: Mozilla Thunderbird

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
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
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).
+ * 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]