Re: Plugin Register Accesses

[Aaron Lindsay via <qemu-devel@nongnu.org>]

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.

-Aaron