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. Stefan
signature.asc
Description: PGP signature
