Re: [Qemu-devel] [RFC PATCH 00/21] Trace updates and plugin RFC

[Alex Bennée]

Emilio G. Cota <address@hidden> writes:

> On Mon, Oct 08, 2018 at 11:28:38 +0100, Alex Bennée wrote:
>> Emilio G. Cota <address@hidden> 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.

Right that would be useful.

>
>> >> 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.

It would be nice if the logic the inserts the trace helper vs a direct
call could be shared. I guess I'd have to see the implementation to see
how ugly it gets.

>
>> > 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.

But we can avoid having plugin-points and trace-events duplicating stuff
as well? I guess you want to avoid having the generated code fragments
for plugins?

The other nice property was avoiding re-duplicating output logic for
"filter" style operations. However I didn't actually included such an
example in the series. I was pondering a QEMU powered PLT/library call
tracer to demonstrate that sort of thing.

> 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).

Sounds good.

>
> Thanks,
>
>               Emilio


--
Alex Bennée