I am personally in favor to adding such features in upstream QEMU, but we
should discuss it with the maintainers, because it would allow to change the
state of execution, which is something qemu plugins actively didn't try to do.
It's a real paradigm shift for plugins.
By writing to memory/registers, we can start replacing instructions and control
flow, and there is a whole set of consequences to that.
Totally agree! As much as I really want this functionality for plugins, I think
alignment on it is quite important. I can see very cool use cases for being
able to replace instructions and control flow to allow hooking functions,
hotpatching, and so forth.
I don't really know the edge cases here so your expertise will be helpful. In
the worst case I can imagine: what would happen if a callback overwrote the
next insn? I'm not sure what behavior I would expect if that insn has already
been translated as part of the same tb. That said, the plugin is aware of which
insns have already been translated, so maybe it is not unreasonable to just
document this as a "don't do that". Let me know what you think.
The hypercall functionality would be useful for plugins as a whole. And I think
it definitely deserves to be worked on, if maintainers are open to that as well.
Sure, I'd be happy to work on this some more. At least on the fuzzing side of
things, the way hypercalls are done across hypervisors (QEMU, Bochs, etc) is
pretty consistent so I think we could provide a useful common set of
functionality. The reason I did the bare minimum here is I'm not familiar with
every architecture, and a good NOP needs to be chosen for each one along with a
reasonable way to pass some arguments -- I don't know if I'm the right person
to make that call.