On 07/06/2017 17:52, Lluís Vilanova wrote: > Paolo Bonzini writes: > >> On 07/06/2017 14:07, Peter Maydell wrote: >>>> My understanding was that adding a public instrumentation interface would >>>> add >>>> too much code maintenance overhead for a feature that is not in QEMU's core >>>> target. >>> Well, it depends what you define as our core target :-) >>> I think we get quite a lot of users that want some useful ability >>> to see what their guest code is doing, and these days (when >>> dev board hardware is often very cheap and easily available) > >> and virtualization is too... > > Actually, in this case I was thinking of some way to transition between KVM > and > TCG back and forth to be able to instrument a VM at any point in time.
That's not really easy because KVM exposes different hardware (on x86: kvmclock, hypercalls, x2apic, more MSRs). But we are digressing. >> Related to this is also Alessandro's work to librarify TCG (he has a >> TCG-> LLVM backend for example). > > Maybe I misunderstood, but that would be completely orthogonal, even though > instrumentation performance might benefit from LLVM's advanced IR > optimizers. It is different, but it shows the interest in bringing QEMU's translation engine (the front-end in Alessandro's case, the back-end in yours) beyond the simple usecase of dynamic recompilation. Paolo > But this goes a long way to hot code identification and asynchronous > optimization (since code that is not really hot will just run faster with > simpler optimizations, like in the TCG compiler). This actually sounds pretty > much like Java's HotSpot, certainly a non-trivial effort. > > > Cheers, > Lluis >