Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
On 12/6/24 16:57, Rowan Hart wrote:
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 think currently that makes quite a lot of demands on the translator to
make sure things are kept consistent.
We have been talking about maybe enabling hypercalls of some sort to
allow for hooking explicit function boundaries in linux-user. A natural
extension of that would be for host library bypass functions. I'm unsure
of how that would apply in system emulation mode though where things are
handled on a lot more granular level.
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.
In the end, if we implement something to modify running code, we
should make sure it works as expected (flushing the related tb). I am
not sure about the current status, and all the changes that would be
needed, but it's something we should discuss before implementing.
If the right access helpers are used we eventually end up in cputlb and
the code modification detection code will kick in. But that detection
mechanism relies on the guest controlled page tables marking executable
code and honouring rw permissions. If plugins don't honour those
permissions you'll become unstuck quite quickly.
More globally, let's wait to hear feedback from maintainers to see if
they are open to the idea or not. A "hard" no would end it there.
It's not a hard no - but I think any such patching ability would need a
quite a bit of thought to make sure edge cases are covered. However I do
expect there will be downstream forks that go further than the upstream
is currently comfortable with and if the code is structured in the right
way we can minimise the pain of re-basing.