I know now as how the helper methods called for address translation. In case of slow path, the address translation is done at the end of block by method "tcg_out_tb_finalize". Any specific reasons for it ?
Thanks, Gaurav On 2/10/14, Gaurav Sharma <gauravs.2...@gmail.com> wrote: > Sorry if i am a bit slow on this, > 1. For ld/st do we will always have a mapping in the CPUTLBEntry ? > 2. I see a lot helper functions in /include/exec/software_template.h , > from where and how do these come into picture ? > 3. When is the TLB populated for addresses within RAM device ? > > On 2/10/14, Peter Maydell <peter.mayd...@linaro.org> wrote: >> 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 >> >