qemu plugin exposure of register addresses

qemu plugin exposure of register addresses

[Robert Henry]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

There is now a qemu plugin interface function qemu_plugin_register_vcpu_mem_cb which registers a plugin-side callback. This callback is later invoked at the start of each emulated instruction, and it receives information about memory addresses and read/write indicators.

I'm wondering how hard it is to add a similar callback to expose register addresses and read/write indicators.  For example, executing `add r3, r1, $1` would generate two callbacks, one {write r3} and the other {read r1}. I'd like this for all kinds of registers such as simd regs, and, gulp, flags registers.

With this information ISA simulators could examine the data flow graph and register dependencies.

I'm not asking for register contents; we don't get memory contents either!

I gather there is some concern about exposing too much functionality to the plugin API, as a plugin might then be used to subvert some aspects of the GPL.  I don't understand the details of this concern, nor know where the "line in the sand" is.

Robert Henry

[-- Attachment #2: Type: text/html, Size: 2529 bytes --]

Re: qemu plugin exposure of register addresses

[Alex Bennée]

Robert Henry <robhenry@microsoft.com> writes:

> There is now a qemu plugin interface function
> qemu_plugin_register_vcpu_mem_cb which registers a plugin-side
> callback. This callback is later invoked at the start of each emulated
> instruction, and it receives information about memory addresses and
> read/write indicators.
>
> I'm wondering how hard it is to add a similar callback to expose
> register addresses and read/write indicators.  For example, executing
> `add r3, r1, $1` would generate two callbacks, one {write r3} and the
> other {read r1}. I'd like this for all kinds of registers such as simd
> regs, and, gulp, flags registers.

The problem with tracking registers directly from the plugin is the
internal variability of how QEMU does things. The core TCG isn't really
aware of registers as such and the individual translators can take all
sorts of approaches to loading and storing the results. Then you have
the issue of helper functions which TCG is only vaguely aware of if it
needs to save "globals" or not.

> With this information ISA simulators could examine the data flow graph
> and register dependencies.

The plugin itself can still do this by disassembling the instruction at
translation time and decoding which registers are going to be accessed.
It can pass this data to the callback via userdata mechanism.

> I'm not asking for register contents; we don't get memory contents
> either!

There is no conceptual problem with adding access to register contents
even if it's only read-only. The main issue is coming up with a clean
API for it.

See thread @

  Subject: Re: Qemu TCG Plugins - how to access guest registers?
  In-reply-to: <20200329111311.272958fe@luklap>
  Date: Mon, 30 Mar 2020 16:15:47 +0100
  Message-ID: <878sjhho0s.fsf@linaro.org>


> I gather there is some concern about exposing too much functionality
> to the plugin API, as a plugin might then be used to subvert some
> aspects of the GPL.  I don't understand the details of this concern,
> nor know where the "line in the sand" is.

We need to better document this - but basically we don't want 3rd
parties implementing what would be core functionality (e.g. device
models) but using plugins as some sort of end run around the GPL. While
I would love there to be more analysis plugins contributed upstream it's
less of a concern.

>
> Robert Henry


-- 
Alex Bennée