[Qemu-devel] [TCG] : Code flow understanding

[Qemu-devel] [TCG] : Code flow understanding

[Gaurav Sharma]

I am working on something where i need to use the primarily the TCG
part of qemu.
I am aware of the basic code flow for TB generation, execution etc.
What I am really looking is the entry / exit points for TCG and also
how the mapping of registers is done. I see there are many temporaries
created and then are mapped to the CPUARCHState.
I am digging more in to the code as of now.
I need some help regarding the flow of generating a TCG op and then
subsequent translation of any op into target instrn.

Re: [Qemu-devel] [TCG] : Code flow understanding

[Richard Henderson]

On 02/05/2014 11:22 PM, Gaurav Sharma wrote:
> I need some help regarding the flow of generating a TCG op and then
> subsequent translation of any op into target instrn.

That's most of tcg/tcg.c and tcg/foo/tcg-target.c.

tcg_gen_code is the main entry point for beginning the compilation
of the previously emitted tcg ops.


r~

Re: [Qemu-devel] [TCG] : Code flow understanding

[Gaurav Sharma]

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 ?

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 ?

On 2/8/14, Richard Henderson <rth@twiddle.net> wrote:
> On 02/05/2014 11:22 PM, Gaurav Sharma wrote:
>> I need some help regarding the flow of generating a TCG op and then
>> subsequent translation of any op into target instrn.
>
> That's most of tcg/tcg.c and tcg/foo/tcg-target.c.
>
> tcg_gen_code is the main entry point for beginning the compilation
> of the previously emitted tcg ops.
>
>
> r~
>

Re: [Qemu-devel] [TCG] : Code flow understanding

[Peter Maydell]

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

Re: [Qemu-devel] [TCG] : Code flow understanding

[Gaurav Sharma]

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.maydell@linaro.org> wrote:
> On 10 February 2014 09:46, Gaurav Sharma <gauravs.2010@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
>

Re: [Qemu-devel] [TCG] : Code flow understanding

[Gaurav Sharma]

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.2010@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.maydell@linaro.org> wrote:
>> On 10 February 2014 09:46, Gaurav Sharma <gauravs.2010@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
>>
>