Aaron Lindsay OS <aa...@os.amperecomputing.com> writes:
> On Jun 28 21:52, Alex Bennée wrote:
>> Aaron Lindsay OS <aa...@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
