Re: [Qemu-devel] [PATCH v3 19/50] tcg: let plugins instrument memory accesses

["Alex Bennée" <alex.bennee@linaro.org>]

Aaron Lindsay OS <aaron@os.amperecomputing.com> writes:

> On Jun 28 21:52, Alex Bennée wrote:
>> Aaron Lindsay OS <aaron@os.amperecomputing.com> writes:
>> > To make sure I understand - you're implying that one such query will
>> > return the PA from the guest's perspective, right?
>>
>> Yes - although it will be two queries:
>>
>>   struct qemu_plugin_hwaddr *hw = qemu_plugin_get_hwaddr(info, vaddr);
>>
>> This does the actual lookup and stores enough information for the
>> further queries.
>>
>>   uint64_t pa = qemu_plugin_hwaddr_to_raddr(hw);
>>
>> will return the physical address (assuming it's a RAM reference and not
>> some IO location).
>
> Sounds good, as long as we have a good way to either prevent or cleanly
> detect the failure mode for the IO accesses.
>
>> > In terms of our use case - we use QEMU to drive studies to help us
>> > design the next generation of processors. As you can imagine, having the
>> > right physical addresses is important for some aspects of that. We're
>> > currently using a version of Pavel Dovgalyuk's earlier plugin patchset
>> > with some of our own patches/fixes on top, but it would obviously make
>> > our lives easier to work together to get this sort of infrastructure
>> > upstream!
>>
>> Was this:
>>
>>  Date: Tue, 05 Jun 2018 13:39:15 +0300
>>  Message-ID: <152819515565.30857.16834004920507717324.stgit@pasha-ThinkPad-T60>
>>  Subject: [Qemu-devel] [RFC PATCH v2 0/7] QEMU binary instrumentation prototype
>
> Yes, that looks like the one.
>
>> What patches did you add on top?
>
> We added:
> - plugin support for linux-user mode (I sent that one upstream, I think)
> - memory tracing support and a VA->PA conversion helper

check

> - a way for a plugin to request getting a callback just before QEMU
>   exits to clean up any internal state

check - qemu_plugin_register_atexit_cb

> - a way for a plugin to reset any instrumentation decisions made in the
>   past (essentially calls `tb_flush(cpu);` under the covers). We found
>   this critical for plugins which undergo state changes during the
>   course of their execution (i.e. watch for event X, then go into a more
>   detailed profiling mode until you see event Y)

check:

/**
 * qemu_plugin_reset() - Reset a plugin
 * @id: this plugin's opaque ID
 * @cb: callback to be called once the plugin has been reset
 *
 * Unregisters all callbacks for the plugin given by @id.
 *
 * Do NOT assume that the plugin has been reset once this function returns.
 * Plugins are reset asynchronously, and therefore the given plugin receives
 * callbacks until @cb is called.
 */
void qemu_plugin_reset(qemu_plugin_id_t id, qemu_plugin_simple_cb_t cb);


> - instrumentation at the TB granularity (in addition to the existing
>   instruction-level support)

check

/**
 * qemu_plugin_register_vcpu_tb_trans_cb() - register a translate cb
 * @id: plugin ID
 * @cb: callback function
 *
 * The @cb function is called every time a translation occurs. The @cb
 * function is passed an opaque qemu_plugin_type which it can query
 * for additional information including the list of translated
 * instructions. At this point the plugin can register further
 * callbacks to be triggered when the block or individual instruction
 * executes.
 */

and then you can have instruction or TB level callbacks:

/**
 * qemu_plugin_register_vcpu_tb_trans_exec_cb() - register execution callback
 * @tb: the opaque qemu_plugin_tb handle for the translation
 * @cb: callback function
 * @flags: does the plugin read or write the CPU's registers?
 * @userdata: any plugin data to pass to the @cb?
 *
 * The @cb function is called every time a translated unit executes.
 */
void qemu_plugin_register_vcpu_tb_exec_cb(struct qemu_plugin_tb *tb,
                                          qemu_plugin_vcpu_udata_cb_t cb,
                                          enum qemu_plugin_cb_flags flags,
                                          void *userdata);

Or the inline equivalent.


> - the ability for a plugin to trigger a checkpoint to be taken

We don't have this at the moment. Pranith also mentioned it in his
review comments. I can see its use but I suspect it won't make the
initial implementation given the broader requirements of QEMU to do
checkpointing and how to cleanly expose that to plugins.

>
> -Aaron


--
Alex Bennée