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

[Aaron Lindsay OS via Qemu-devel <qemu-devel@nongnu.org>]

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
- a way for a plugin to request getting a callback just before QEMU
  exits to clean up any internal state
- 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)
- instrumentation at the TB granularity (in addition to the existing
  instruction-level support)
- the ability for a plugin to trigger a checkpoint to be taken

-Aaron