To mimic QEMUs behavior, we copied the plugin_maybe_preserve_addr function, and used it in the same places as QEMU also does for its memory plugin callbacks.
Note that we copied this and technically repeat the same code, but QEMU disables all those functions when the plugin feature is disabled.
And we do not add extra logic that is found in the plugin mem callback generation function plugin_gen_mem_callbacks because in those specific cases the function will always just use the preserved address anyway. The function just contains the same logic as a fallback when no copy_addr was given as a parameter.
Additionally, we are now correctly using the original memop variable in the same way the plugin callback does. This should now be more consistent.
When using the new QEMU version, the read hooks sometimes returned invalid addresses like 0x1 or 0x1000.
For reference this commit in upstream QEMU is relevant, where the handling for addresses was adjusted: https://gitlab.com/qemu-project/qemu/-/commit/d5920b7280762d4d696bff87f50dbce453adef06
And in https://gitlab.com/qemu-project/qemu/-/commit/eb9d02f24b1ce877a60ffaf6cc1ecc8484740b37 we can see, that QEMU temporarily stores the address in a TCGTemp variable, because it can get corrupted by the operation via overlaps.
To mimic QEMUs behavior, we copied the
plugin_maybe_preserve_addr
function, and used it in the same places as QEMU also does for its memory plugin callbacks.Note that we copied this and technically repeat the same code, but QEMU disables all those functions when the plugin feature is disabled.
And we do not add extra logic that is found in the plugin mem callback generation function
plugin_gen_mem_callbacks
because in those specific cases the function will always just use the preserved address anyway. The function just contains the same logic as a fallback when no copy_addr was given as a parameter.Additionally, we are now correctly using the original memop variable in the same way the plugin callback does. This should now be more consistent.