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

[Alex Bennée]

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.

> 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.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro