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

[Stefan Hajnoczi]

On Wed, Aug 02, 2017 at 06:19:29PM +0300, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
> > On Wed, Aug 02, 2017 at 12:10:14PM +0100, Peter Maydell wrote:
> >> On 2 August 2017 at 12:04, Stefan Hajnoczi <address@hidden> wrote:
> >> > On Tue, Aug 01, 2017 at 02:54:29PM +0100, Peter Maydell wrote:
> >> >> and I don't need the TCG engine to be a library to do that...
> >> >
> >> > You do need TCG APIs if you want TCG-level instrumentation, tuning
> >> > options, callbacks, etc.
> >> 
> >> I need an API; that doesn't necessarily look like the kind
> >> of API you want to be able to embed the TCG engine into
> >> other things, I think.
> >> 
> >> >> I agree that we want to provide something that is at least
> >> >> closer to a stable API than "just expose trace events",
> >> >> though.
> >> >
> >> > libqemu has at least three parts:
> >> >
> >> > 1. VM API (i.e. qemu_init(argc, argv), qemu_run(), qemu_vcpu_get_reg32())
> >> > 2. TCG engine
> >> > 3. Device models
> >> >
> >> > Like I said in my email, start with what matters for the instrumentation
> >> > use case (VM API at a minimum to control guest execution).  Other people
> >> > can flesh out the other parts later, as needed.
> >> >
> >> > Other attempts to provide a stable API will be essentially the same
> >> > thing as libqemu.
> >> 
> >> I don't think this is the case -- you could have a stable
> >> instrumentation API without it looking anything like
> >> libqemu. In particular I don't think you need to have
> >> something that sits at the top level and says 'run'.
> >> 
> >> In particular I think that pulling TCG out of QEMU
> >> is an enormous and painful undertaking that you just
> >> don't need to do at all to allow this kind of
> >> instrumentation API.
> 
> > Please post an example of the API you'd like.
> 
> In my opinion, the instrumentation support in this series provides an API that
> works in the opposite way you're suggesting (let's ignore the fact that it's
> built on tracing events).
> 
> When QEMU loads an instrumentation library (which can happen at any time), 
> some
> initialization function is called on the library so that it can establish what
> events to instrument. This also has the advantage that a user can hook into a
> running QEMU instance at any time to perform some instrumentation.
> 
> I think this is the bare minimum necessary to make it work, and has the upside
> of being completely orthogonal to the libqemu approach. We could reuse most of
> the stable instrumentation API there too, except for the instrumentation code
> initialization.
> 
> That being said, the libqemu approach *might* make it a bit easier to provide 
> an
> API for things such as "run for this many instructions and return control to
> instrumentor", but I don't think that's mandatory for a first prototype (and 
> can
> definitely be implemented using both approaches).

The main concern I have is that a feature for loading shared libraries
and hooking QEMU will be abused.  This can be mostly solved by offering
only a stable API without the ability to hook trace events.  There are
still ways to abuse this and that's why I prefer the libqemu approach.

The libqemu approach also avoids the "how do I enable my
instrumentation?" step for new users because they just need to run their
program after compiling it.  The workflow is simpler.

As a next step I suggest defining the stable instrumentation API and
dropping the tracing hooks.  We can still work out whether shared
library loading or libqemu is okay later but the stable API is most
important.

Stefan

signature.asc
Description: PGP signature