On 8/26/24 11:47, Rowan Hart wrote:
Alex & Pierrick,
Thank you for the feedback! This is my first contribution to QEMU, so I'm glad
it at least passes the initial smell test :)
Sure, no worries, you did well!
I'll make my comments in this patch, but for v2, please split those individual
com
Alex,
Thanks for the additional information.
>>
>> A key aspect of what you propose here, is that the memory may have
>> changed during the write time, and when you read it, while what we
>> propose guarantees to track every change correctly.
>>
>> It's not a bad thing, and both API are definitel
Alex & Pierrick,
Thank you for the feedback! This is my first contribution to QEMU, so I'm glad
it at least passes the initial smell test :)
> I'll make my comments in this patch, but for v2, please split those individual
> commits, and a cover letter, describing your changes (https://github.com/
Pierrick Bouvier writes:
> Hi Rowan, thanks for your contribution.
>
> To give some context on the answer, we are currently working to add a
> similar "read_memory" API, but associated to memory callbacks for
> plugins
> (https://lore.kernel.org/qemu-devel/20240724194708.1843704-1-pierrick.bouv..
On 8/22/24 13:33, Pierrick Bouvier wrote:
+ *
+ * version 3:
+ * - modified arguments and return value of qemu_plugin_insn_data to copy
+ * the data into a user-provided buffer instead of returning a pointer
+ * to the data.
+ *
Is it a change left on your side, or a bad diff?
Just sa
Hi Rowan, thanks for your contribution.
To give some context on the answer, we are currently working to add a
similar "read_memory" API, but associated to memory callbacks for
plugins
(https://lore.kernel.org/qemu-devel/20240724194708.1843704-1-pierrick.bouv...@linaro.org/T/#t).
A key aspect
Signed-off-by: Rowan Hart
---
docs/about/emulation.rst | 16 -
include/qemu/qemu-plugin.h | 24 +++-
plugins/api.c| 21 +++
plugins/qemu-plugins.symbols | 1 +
tests/tcg/plugins/mem.c | 37 +++-
tests/tcg/plugins/syscall.c | 113 ++
