On 10 February 2014 09:46, Gaurav Sharma <gauravs.2...@gmail.com> 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
