On 5/22/25 2:01 PM, Rowan Hart wrote:
> This definition strikes me as odd. What was your reason to assert > `current_cpu` here, but not in the other two functions? Also a bit > surprising is the declaration of `cpu` if you use it in just one place > (rather than just use `current_cpu` directly as for the assertion). > > And there is no reason in particular why the vCPU could not be a > function parameter of `qemu_plugin_translate_vaddr`, right? You don't > have the same restrictions as in `qemu_plugin_read_memory_hwaddr` or > `qemu_plugin_hwaddr_operation_result` where you actually touch memory? > That's a good point, adding a "unsigned int vcpu_index" to the signature should be enough to query current or any other vcpu easily.This is a really nice idea, it might be nice to make a vcpu version of read/write register too. For memory, I'd think going with the current memory is probably fine, I don't see any configs with different memory per vcpu?
Thinking about it twice, and after reading Alex comments for writing registers, it's probably not a good idea to allow such side effects on other vcpus (on registers and memory). In case of registers, there is nothing ensuring they will be written correctly, so it only makes sense for current_cpu, as we are in a callback running on it. Safer to have the same semantic for memory read/write also, so please forget my idea.
