[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [TCG] : Code flow understanding
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [TCG] : Code flow understanding |
Date: |
Mon, 10 Feb 2014 11:04:03 +0000 |
On 10 February 2014 09:46, Gaurav Sharma <address@hidden> wrote:
> I was able to trace the flow to some extent but i still have some queries :
> 1. CPUARCHState is the main structure where we store the register
> info. for e.g. - CPUARMState for ARM. We also main some local
> temporaries cpu_R. So where and how are these temporary values
> committed to the main structure ?
The cpu_R are actually TCG globals which are defined to live
in memory locations (which happen to be in the CPUARMState
structure). So writing to the TCG global in generated code
is by definition writing to the structure field. See tcg/README.
> 2. Where and when will the translation from guest virtual address to
> host virtual address occur. For e.g. for a load instruction for arm
> ldr r1, [r0] where will the address translation happen ?
This is complicated because it needs to be fast. Broadly:
* there is a CPU TLB data structure (cputlb.c) which is
a cache of guest vaddr to host vaddr (or guest vaddr
to IO information for devices)
* generated code for TCG guest ld/st operations directly
looks up in this data structure for the fast path
(eg tcg_out_tlb_load in tcg/i386/tcg-target.c)
* if the fast lookup fails, on the slow path we will
handle the not-RAM cases like device access, and if
there's no TLB entry present at all we call a guest
CPU specific function to do the guest-vaddr to
guest-physaddr lookup (page table walk), do guest
physaddr to host-vaddr if appropriate, and fill in
the TLB entry so we can take the fast path next time
thanks
-- PMM