Re: [PATCH v12 5/7] plugins: Add memory hardware address read/write API

["Alex Bennée" <alex.bennee@linaro.org>]

Rowan Hart <rowanbhart@gmail.com> writes:

> From: novafacing <rowanbhart@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.bouvier@linaro.org>
> Signed-off-by: Rowan Hart <rowanbhart@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