[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support
From: |
Pranith Kumar |
Subject: |
Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support |
Date: |
Thu, 20 Jun 2019 06:53:30 -0700 |
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 <address@hidden> 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: <address@hidden>
>
* 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
- Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support, (continued)
- [Qemu-devel] [PATCH v3 34/50] target/sparc: fetch code with translator_ld, Alex Bennée, 2019/06/14
- [Qemu-devel] [PATCH v3 22/50] *-user: plugin syscalls, Alex Bennée, 2019/06/14
- [Qemu-devel] [PATCH v3 41/50] tests/plugin: add sample plugins, Alex Bennée, 2019/06/14
- [Qemu-devel] [PATCH v3 45/50] tests/plugin: add instruction execution breakdown, Alex Bennée, 2019/06/14
- Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support, no-reply, 2019/06/14
- Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support, no-reply, 2019/06/14
- Re: [Qemu-devel] [PATCH v3 00/50] tcg plugin support,
Pranith Kumar <=