Re: [Qemu-devel] [PATCH 00/13] instrument: Add basic event instrumentation

From: "Lluís Vilanova" <vilanova@ac.upc.edu>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	"Emilio G. Cota" <cota@braap.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 00/13] instrument: Add basic event instrumentation
Date: Fri, 28 Jul 2017 19:21:04 +0300	[thread overview]
Message-ID: <877eyslehb.fsf@frigg.lan> (raw)
In-Reply-To: <20170728134218.GT12364@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Fri, 28 Jul 2017 14:42:18 +0100")

Stefan Hajnoczi writes:

> On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote:
>> On 27 July 2017 at 11:32, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> > On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
>> >> And why exactly is this a threat? Because it can be used to "extend" QEMU
>> >> without touching its sources? Is this a realistic threat? (it's a rather brittle
>> >> way to do it, so I'm not sure it's practical)
>> >
>> > Unfortunately it is a problem.  I recently came across a product that
>> > was using LD_PRELOAD= to "integrate" with QEMU.  People really abuse
>> > these interfaces instead of integrating their features cleanly into
>> > QEMU.
>> 
>> ...if people who want to do this kind of thing already can and
>> do use LD_PRELOAD for it, I don't think we should worry too much
>> about trying to make the instrumentation plugin API bulletproof
>> against similar abuse.
>> 
>> > I see the use cases that Peter has been describing and am sure we can
>> > come up with good solutions.  What I care about is that it doesn't allow
>> > loading a .so that connects to arbitrary trace events.
>> 
>> That said, I agree that we don't really need an arbitrary-trace-event
>> setup here, and we should probably design our API so that it isn't
>> handing the trace plugin hooks pointers into QEMU's internals.
>> We want an API that makes it easy for people to do things based on
>> changes of the guest binary's state (registers, insns, etc etc)
>> and which makes it hard for them to accidentally trip themselves up
>> (eg by prodding around in QEMU internal data structures).
>> This will have the secondary benefit that it's unlikely that future
>> changes to QEMU will break plugin code.
>> 
>> >> As a side note, I find instrumentation to be most useful for guest code events,
>> >> which mostly contain non-pointer values (except for the CPUState*).
>> 
>> For instance we definitely should not be passing a CPUState* to
>> any plugin function.

> The gdbstub protocol has relevant features for accessing guest memory,
> registers, etc.  Perhaps a set of QEMU-specific events can be added
> (e.g. tb generated) so it's possible to instrument and control the
> guest from an instrumentation program (written in any language).

> Perhaps there is a fundamental reason why this isn't possible due to the
> protocol design, because using gdbstub halts all vcpus, etc.  I don't
> know.

> Do you think this is an interesting direction?  It definitely seems like
> a powerful approach though performance would be less than running native
> code inside the QEMU process.

That's the same approach someone else dubbed as using a fifo with "synchronous"
events, right? I have some measurements on this using a pipe, and overheads are
1000x to 2300x for each communication event (compared to a function call, and
depending on whether each process/thread is pinned to the same or different
CPU).

Cheers,
  Lluis