On Dec 08 14:44, Aaron Lindsay wrote: > On Dec 08 17:56, Alex Bennée wrote: > > Aaron Lindsay <aa...@os.amperecomputing.com> writes: > > > On Dec 08 12:17, Alex Bennée wrote: > > >> Aaron Lindsay <aa...@os.amperecomputing.com> writes: > > >> Memory is a little trickier because you can't know at any point if a > > >> given virtual address is actually mapped to real memory. The safest way > > >> would be to extend the existing memory tracking code to save the values > > >> saved/loaded from a given address. However if you had register access > > >> you could probably achieve the same thing after the fact by examining > > >> the opcode and pulling the values from the registers. > > > > > > What if memory reads were requested by `qemu_plugin_hwaddr` instead of > > > by virtual address? `qemu_plugin_get_hwaddr()` is already exposed, and I > > > would expect being able to successfully get a `qemu_plugin_hwaddr` in a > > > callback would mean it is currently mapped. Am I overlooking > > > something? > > > > We can't re-run the transaction - there may have been a change to the > > memory layout that instruction caused (see tlb_plugin_lookup and the > > interaction with io_writex). > > To make sure I understand, your concern is that such a memory access > would be made against the state from *after* the instruction's execution > rather than before (and that my `qemu_plugin_hwaddr` would be a > reference to before)? > > > However I think we can expand the options for memory instrumentation > > to cache the read or written value. > > Would this include any non-software accesses as well (i.e. page table > reads made by hardware on architectures which support doing so)? I > suspect you're going to tell me that this is hard to do without exposing > QEMU/TCG internals, but I'll ask anyway! > > > > I think I might actually prefer a plugin memory access interface be in > > > the physical address space - it seems like it might allow you to get > > > more mileage out of one interface without having to support accesses by > > > virtual and physical address separately. > > > > > > Or, even if that won't work for whatever reason, it seems reasonable for > > > a plugin call accessing memory by virtual address to fail in the case > > > where it's not mapped. As long as that failure case is well-documented > > > and easy to distinguish from others within a plugin, why not? > > > > Hmmm I'm not sure - I don't want to expose internal implementation > > details to the plugins because we don't want plugins to rely on them. > > Ohhh, was your "you can't know [...] mapped to real memory" discussing > whether it was currently mapped on the *host*? > > I assumed you were discussing whether it was mapped from the guest's > point of view, and therefore expected that whether a guest VA was mapped > was a function of the guest code being executed, and not of the TCG > implementation. I confess I'm not that familiar with how QEMU handles > memory internally.
I'm trying to understand the issue here a little more... does calling `cpu_memory_rw_debug()` not work because it's not safe to call in a plugin instruction-execution callback? Is there any way to make that sort of arbitrary access to memory safely? -Aaron
