On Mon, Oct 08, 2018 at 11:28:38 +0100, Alex Bennée wrote:
> Emilio G. Cota <c...@braap.org> writes:
> > Again, for performance you'd avoid the tracepoint (i.e. calling
> > a helper to call another function) and embed directly the
> > callback from TCG. Same thing applies to TB's.
>
> OK I see what you mean. I think that is doable although it might take a
> bit more tcg plumbing.
I have patches to do it, it's not complicated.
> >> So what do people think? Could this be a viable way to extend QEMU
> >> with plugins?
> >
> > For frequent events such as the ones mentioned above, I am
> > not sure plugins can be efficiently implemented under
> > tracing.
>
> I assume some form of helper-per-instrumented-event/insn is still going
> to be needed though? We are not considering some sort of EBF craziness?
Helper, yes. But one that points directly to plugin code.
> > For others (e.g. cpu_init events), sure, they could.
> > But still, differently from tracers, plugins can come and go
> > anytime, so I am not convinced that merging the two features
> > is a good idea.
>
> I don't think we have to mirror tracepoints and plugin points but I'm in
> favour of sharing the general mechanism and tooling rather than having a
> whole separate set of hooks. We certainly don't want anything like:
>
> trace_exec_tb(tb, pc);
> plugin_exec_tb(tb, pc);
>
> scattered throughout the code where the two do align.
We could have something like
plugin_trace_exec_tb(tb, pc);
that would expand to the two lines above. Or similar.
So I agree with you that in some cases the "trace points"
for both tracing and plugin might be the same, perhaps
identical. But that doesn't necessarily mean that making
plugins a subset of tracing is a good idea.
I think sharing my plugin implementation will help the
discussion. I'll share it as soon as I can (my QEMU plate
is full already trying to merge a couple of other features
first).
Thanks,
Emilio
