Well, first I just noticed that I left a debug print in this function!
So I'll fix that.
Reading this patch, and patch 3 (Add address space API), I am not sure
AddressSpace is something we want to leak in plugins interface.
It is a concept *very* internal to QEMU, and not reflecting directly
something concerning the emulated architecture (it is related, but not
officially described for it).
The same way qemu_plugin_write_memory_vaddr is only valid in the
current page table setup, we could assume the same for current address
space, and return an error if memory is not mapped with current AS.
Eventually, we could read/write a given hwaddr in all existing address
spaces (starting with current mapped one), if it makes sense to do
this, which I'm not sure about.
What are your thoughts on this?
I definitely see the arguments for not exposing it even as an opaque
struct, internality not withstanding it also adds some complexity for
plugin authors.
My thought with exposing it is kind of twofold. First, there are
specific address spaces like the secure address space on ARM or I/O
memory on x86 that plugins might like to access and I think it's easiest
to facilitate that if we just let them choose which one they want to r/w
to. Second, I wanted to lean towards being less restrictive now to avoid
having to go back and remove restrictions later since even though it's
very internal, it doesn't seem very likely to change.
That said, if you think it's more trouble than it's worth I'm totally
fine with just defaulting to writing to the current AS (or to
cpu-memory, whichever's more reasonable). Your call, just let me know
which way you think is best for v4 :)
qemu_plugin_translate_vaddr is fine for me.
I did have a question about this -- one of the test plugins prints out
vaddr, haddr from qemu_plugin_insn_haddr, and the translated haddr from
qemu_plugin_translate_vaddr. When running with direct memory mappings in
a system test, the vaddr = translated haddr, which is correct, but the
haddr from qemu_plugin_insn_haddr was incorrect (it was 0x7f....f<actual
address>). Is this expected behavior?
Thanks for the feedback!
