Re: [Qemu-devel] Virtual Address translation in QEMU

[Peter Maydell]

On 15 November 2013 23:37, Fardin Abdi <address@hidden> wrote:
> I need to deal with all the load and store functions in ARM architecture.
> Basically, I want to record all the load and store instructions along with
> their address.
>
> There is a TLB in QEMU that is flushed with every context switch. So, as I
> understand, for every data request to memory, QEMU looks up in the table to
> see if there is a physical translation, otherwise, it fetches the page table
> and translates the vritual address.

Not exactly. We take the guest virtual address and look it up in our
TLB; if we get a hit that gives us the host virtual address in RAM then
we can directly load/store. (Note that in this fast path the guest physical
address never appears.) Otherwise we will take a slower path; this
may still be able to do a fairly direct lookup from a TLB entry to an
IO TLB entry which gives us pointers to emulated device load/store
functions. If all else fails we'll do a TLB fill (which will do a page table
walk).

> What I want to find, is the function in QEMU source code that is calling the
> TLb and checks wether there is a entry in the TLB or not.

There is no single such function, because we emit native code for
the host system which does this lookup inline. (For example, on
x86 this is done in tcg/i386/tcg-target.c:tcg_out_tlb_load().) We
also repeat the TLB lookup in the slowpath functions I think.

Note also that at the point where we are doing this we do not
know what the guest program counter is. (Updating the PC
for every instruction executed would be very slow, so we only
do it at the end of basic blocks or in a complicated fixup process
that happens for unexpected exceptions like abort on load/store.)

For what you seem to want I would suggest you would be better
adding code to the ARM frontend so that for every load/store it also
emits a call to a helper function which you can use to record
information about it.

Other people have been down this road of trying to instrument
QEMU before -- you may be able to find some of their work
if you search. It hasn't gone upstream because it's difficult
to do it  in a way that doesn't compromise speed or
maintainability.

-- PMM