Rowan Hart <rowanbh...@gmail.com> writes: > From: novafacing <rowanbh...@gmail.com> > > This patch adds functions to the plugins API to allow plugins to read > and write memory via hardware addresses. The functions use the current > address space of the current CPU in order to avoid exposing address > space information to users. A later patch may want to add a function to > permit a specified address space, for example to facilitate > architecture-specific plugins that want to operate on them, for example > reading ARM secure memory. > > Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org> > Signed-off-by: Rowan Hart <rowanbh...@gmail.com> <snip> > +/** > + * qemu_plugin_write_memory_hwaddr() - write to memory using a hardware > address > + * > + * @addr: A physical address to write to > + * @data: A byte array containing the data to write > + * > + * The contents of @data will be written to memory starting at the hardware > + * address @addr in the current address space for the current vCPU. > + * > + * This function does not guarantee consistency of writes, nor does it ensure > + * that pending writes are flushed either before or after the write takes > place, > + * so callers should take care when calling this function in plugin > callbacks to > + * avoid depending on the existence of data written using this function which > + * may be overwritten afterward. In addition, this function requires that the > + * pages containing the address are not locked. Practically, this means that > you > + * should not write instruction memory in a current translation block inside > a > + * callback registered with qemu_plugin_register_vcpu_tb_trans_cb. > + * > + * You can, for example, write instruction memory in a current translation > block > + * in a callback registered with qemu_plugin_register_vcpu_tb_exec_cb, > although > + * be aware that the write will not be flushed until after the translation > block > + * has finished executing. In general, this function should be used to write > + * data memory or to patch code at a known address, not in a current > translation > + * block.
My main concern about the long list of caveats for writing memory is the user will almost certainly cause weird things to happen which will then be hard to debug. I can see the patcher example however it would be useful to know what other practical uses this interface provides. <snip> -- Alex Bennée Virtualisation Tech Lead @ Linaro
