Bastian Koppelmann writes: > Hi Peter, > thank you for your feedback.
>> (2) it feels a bit unpolished at the moment (lack of documentation, >> doesn't have any existing analysis tools that produce the format that >> the code reads that would make it immediately usable by an end-user) >> > Sure this is unpolished but we wanted to get feedback before we put too > much work into it. >> I think that a design that would likely get better traction here with >> QEMU upstream would be one where you had tracepoints for relevant >> events like "executing new TB", and some means of writing a plugin >> to run code on those events, or perhaps just a post-analysis tool that >> ran on the trace file. Then the code for reading XML and adding up the >> relevant annotations would be confined to the plugin and wouldn't >> necessarily need to be upstream at all. >> > We like your idea of a "plugin-api" that exposes hooks for relevant > events since this is more generic than our approach. We came up with a > list of relevant events for tracing: > - pre-/post-execute_tb > - pre-/post-translate_tb > - pre-/post-interrupt > (- memory access) > These are the hooks that would be sufficient for our ideas for plugins. > Do you have more suggestions for suitable hooks? Also, is there anything > similar already in QEMU on which we could build on? There is this modified version I wrote [1], which precisely provides a plugin infrastructure to attach callbacks into guest code events (a binary instrumentation framework based on QEMU). At the time, the discussion resolved that a full code instrumentation interface for plugins was too much code that regular QEMU users & developers would not care about, easily leading to bitrot. Instead, the list resolved (AFAIU) that it would be better to mainstream support for guest code events, and make instrumentation an unofficial extension. I've been (slowly) working to separate both pieces, making instrumentation a QEMU patch that can be easily maintained out of tree. The last patch series I sent sets the final stone on the core infrastructure for the mainline part, just missing the patches I have queued to start adding guest code trace events. So, I'd say that such support is on the list of current developments (at least mine, specially now that I have a bit more time for it). But getting the core infrastructure mainlined takes some time to ensure it makes sense and can be easily maintained and be generally usefull to vanilla QEMU. [1] https://projects.gso.ac.upc.edu/projects/qemu-dbi The code is not up-to-date with the latest QEMU Cheers, Lluis