Re: Plugin Register Accesses

[Aaron Lindsay]

On Dec 08 14:44, Aaron Lindsay wrote:
> On Dec 08 17:56, Alex Bennée wrote:
> > Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> > > On Dec 08 12:17, Alex Bennée wrote:
> > >> Aaron Lindsay <aaron@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