Hi Alex/Emilio, I am really happy to see the progress you made on the plugin feature. Looking forward to seeing it merged soon! Please CC me on future versions of the patchset. I am happy to help review and contribute to this effort.
I have a few general comments from experience writing a very similar system (qsim) below. On Fri, Jun 14, 2019 at 10:23 AM Alex Bennée <alex.ben...@linaro.org> wrote: > > Hi, > > This is v3 of the proposed plugins API for QEMU. As Emilio is busy > having finished his time at Columbia I have volunteered to take the > patch series forward. Emilio's RFC v2 was posted last year: > > Subject: [RFC v2 00/38] Plugin support > Date: Sun, 9 Dec 2018 14:37:11 -0500 > Message-Id: <20181209193749.12277-1-c...@braap.org> > * Register and memory read/write API It would be great to have register and memory read/write API i.e., ability to read/write to registers/memory from within the callback. This gives the plugin ability to do system introspection. (Not sure if the current patchset implements this already). * Register callbacks A callback needs to be invoked whenever a specified registers is read or written to. * Where do new plugins live in the tree? The current source files in plugins (api, core etc.,) I think are better if moved to tcg/plugins/. The various plugins we write would then live in the plugins/ folder instead of the current tests/plugin/ folder. * Timer interrupts What I observed is that the system execution is affected by what you do in the callbacks because of timer interrupts. For example, if you spend time in the memory callback doing a bit of processing and writing to a file, you will see more timer interrupt instructions. One solution to this would be to use 'icount', but it does not work that well. I think we need to do something similar to what gdb does in debug mode. How would you handle MTTCG guests in that case? Another approach would be to offload callback generation to a separate plugin thread. The main thread will copy data required by a callback and invoke the callback asynchronously (std::async in C++ if you are familiar). * Starting and stopping callback generation It would be great if we have a mechanism to dynamically start/stop callbacks when a sequence of code (magic instruction) is executed. This would be useful to annotate region-of-interest (ROI) in benchmarks to generate callbacks. Also, the return value from a callback can be used to decide further course of action. For example, if our plugin needs 10000 callbacks, it can indicate to stop generating further callbacks in the return value of the callback once it got the necessary callbacks. * State saving API An API to save the state of the VM from the plugin code. Let me know your thoughts and any other ideas you might have. Thanks, -- Pranith
