Re: Plugin Register Accesses

[Alex Bennée]

Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> 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?

It would be safe on a halted system. However you might not get the same
data back as the load/store instruction just executed if the execution
of the instruction caused a change in the page table mappings. For
example on ARM M-profile writing to the mmio MPU control registers will
flush the current address mappings. For example:

  1. access page X
  2. update architecture page tables for page X -> Y
  3. write to MPU control register, trigger tlb_flush
  4. access page X from plugin -> get Y results

IOW accessing cpu_memory_rw_debug from a instrumented load/store helper
for the address just accessed would be fine for that particular address
because nothing will replace the TLB entry while in the helper. However
as a generalised access to memory things may have changed.

I think we can store enough data for a helper like:

  qemu_plugin_hwaddr_get_value(const struct qemu_plugin_hwaddr *haddr)

but we would certainly want to cache the values io_readx and io_writex
use as they will otherwise be lost into the depths of the emulation.

>
> -Aaron


-- 
Alex Bennée