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 <stefa...@redhat.com> 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). Cheers, Lluis
