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.