[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [TCG] : Code flow understanding
From: |
Gaurav Sharma |
Subject: |
Re: [Qemu-devel] [TCG] : Code flow understanding |
Date: |
Mon, 10 Feb 2014 19:58:40 +0530 |
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 <address@hidden> 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 <address@hidden> wrote:
>> 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
>>
>