[Qemu-devel] Call Trace for QEMU functions

[Qemu-devel] Call Trace for QEMU functions

[Naman patel]

[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]

Hi,

     I have compiled QEMU (2.0) for x86_64 on Fedora 22 with tracing
enabled and the tracing option I chose was dtrace. I have this script
called callTrace.stp in which I try and get the Call Trace of the function
*helper_invlpg *and later *tlb_flush.*  But I am not able to get the
function name of the caller function and the call trace depth is only
limited to 2.

*probe process("/usr/bin/qemu-system-x86_64").function("helper_invlpg") {*
*                printf("gen_helper_invlpg called \n");*
*                        print_usyms(ubacktrace())*
*}*


I run it using following command: *sudo stap -d
/usr/local/bin/qemu-system-x86_64 --ldd --vp 08 *callTrace*.stp*

Following is the ouput:
*gen_helper_invlpg called *
* 0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]*
* 0x7faac5cfcd8c : 0x7faac5cfcd8c*
*gen_helper_invlpg called *
* 0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]*
* 0x7faac5cfcd8c : 0x7faac5cfcd8c*
*gen_helper_invlpg called *
* 0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]*
* 0x7faac5cfcd8c : 0x7faac5cfcd8c*

and so on...

It does not show the function name but the address from where it was
called. Does it mean that its not possible to get backtrace for this
function???

Similarly if I probe for *tlb_flush *then I get the following output:
TLB FULSH called
 0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
 0x7faac6ab5722 : 0x7faac6ab5722
TLB FULSH called
 0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
 0x7faac6b689be : 0x7faac6b689be
TLB FULSH called
 0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
 0x7faac6a74998 : 0x7faac6a74998
TLB FULSH called
 0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
 0x7faac6b689be : 0x7faac6b689be

Here also I am not able to get full Call Trace.

If I do this similar kind of probe using stap -d /bin/ls --ldd -e 'probe
process("ls").function("xmalloc") {print_usyms(ubacktrace())}' -c "ls /"
then I do get proper call trace, Check the following output.
*0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]*
* 0x4114c4 : xmemdup+0x14/0x30 [/usr/bin/ls]*
* 0x40eb4a : clone_quoting_options+0x2a/0x40 [/usr/bin/ls]*
* 0x4033e2 : main+0xa52/0x2160 [/usr/bin/ls]*
* 0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so
<http://libc-2.21.so/>]*
* 0x404b19 : _start+0x29/0x30 [/usr/bin/ls]*
* 0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]*
* 0x4114c4 : xmemdup+0x14/0x30 [/usr/bin/ls]*
* 0x40eb4a : clone_quoting_options+0x2a/0x40 [/usr/bin/ls]*
* 0x403441 : main+0xab1/0x2160 [/usr/bin/ls]*
* 0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so
<http://libc-2.21.so/>]*
* 0x404b19 : _start+0x29/0x30 [/usr/bin/ls]*
* 0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]*
* 0x40378f : main+0xdff/0x2160 [/usr/bin/ls]*
* 0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so
<http://libc-2.21.so/>]*

Do you have any clue why this could happen? Or any alternative approach to
get the call trace?

This is my first email on the group so please pardon me if I have not
followed some customs.

Regards,
Naman

[-- Attachment #2: Type: text/html, Size: 7107 bytes --]

Re: [Qemu-devel] Call Trace for QEMU functions

[Peter Maydell]

On 30 July 2015 at 13:20, Naman patel <naman321@gmail.com> wrote:
> Hi,
>
>      I have compiled QEMU (2.0) for x86_64 on Fedora 22 with tracing enabled
> and the tracing option I chose was dtrace. I have this script called
> callTrace.stp in which I try and get the Call Trace of the function
> helper_invlpg and later tlb_flush.  But I am not able to get the function
> name of the caller function and the call trace depth is only limited to 2.

The helper_invlpg function is called directly from code generated
by QEMU's built-in JIT, not from any other C function.

If you use a newer version of QEMU than 2.0 then I think we have
fixed some of the stack frame information up so that you can
get a backtrace that looks like:
 * helper function
 * [generated code]
 * QEMU execution loop code that handles executing guest code
 * other QEMU functions

This is not likely to be very useful for profiling why or when
we're calling a particular helper function, though.

thanks
-- PMM

Re: [Qemu-devel] Call Trace for QEMU functions

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 30 July 2015 at 13:20, Naman patel <naman321@gmail.com> wrote:
>> Hi,
>>
>>      I have compiled QEMU (2.0) for x86_64 on Fedora 22 with tracing enabled
>> and the tracing option I chose was dtrace. I have this script called
>> callTrace.stp in which I try and get the Call Trace of the function
>> helper_invlpg and later tlb_flush.  But I am not able to get the function
>> name of the caller function and the call trace depth is only limited to 2.
>
> The helper_invlpg function is called directly from code generated
> by QEMU's built-in JIT, not from any other C function.
>
> If you use a newer version of QEMU than 2.0 then I think we have
> fixed some of the stack frame information up so that you can
> get a backtrace that looks like:
>  * helper function
>  * [generated code]
>  * QEMU execution loop code that handles executing guest code
>  * other QEMU functions
>
> This is not likely to be very useful for profiling why or when
> we're calling a particular helper function, though.

With the perf JIT patch you can get a better handle on the profile. I'll
see if I can re-spin them tomorrow for the latest tree.

>
> thanks
> -- PMM

-- 
Alex Bennée

Re: [Qemu-devel] Call Trace for QEMU functions

[Naman patel]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

​Thanks Alex and Peter for this useful information. Looks like the stack
information is not available for this functions in QEMU 2.0.

Can someone explain me what happens when a guest OS calls "invlpg" on say
page swap out or a context switch? What exactly is the call flow and how
QEMU handles this instruction? Also is there anyway QEMU can send some data
back to the guest OS?

P.S. : Sorry if my questions look like generic queries but I am kinda of
stuck here.

On Thu, Jul 30, 2015 at 8:34 PM, Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On 30 July 2015 at 13:20, Naman patel <naman321@gmail.com> wrote:
> >> Hi,
> >>
> >>      I have compiled QEMU (2.0) for x86_64 on Fedora 22 with tracing
> enabled
> >> and the tracing option I chose was dtrace. I have this script called
> >> callTrace.stp in which I try and get the Call Trace of the function
> >> helper_invlpg and later tlb_flush.  But I am not able to get the
> function
> >> name of the caller function and the call trace depth is only limited to
> 2.
> >
> > The helper_invlpg function is called directly from code generated
> > by QEMU's built-in JIT, not from any other C function.
> >
> > If you use a newer version of QEMU than 2.0 then I think we have
> > fixed some of the stack frame information up so that you can
> > get a backtrace that looks like:
> >  * helper function
> >  * [generated code]
> >  * QEMU execution loop code that handles executing guest code
> >  * other QEMU functions
> >
> > This is not likely to be very useful for profiling why or when
> > we're calling a particular helper function, though.
>
> With the perf JIT patch you can get a better handle on the profile. I'll
> see if I can re-spin them tomorrow for the latest tree.
>
> >
> > thanks
> > -- PMM
>
> --
> Alex Bennée
>

[-- Attachment #2: Type: text/html, Size: 3326 bytes --]

Re: [Qemu-devel] Call Trace for QEMU functions

[Peter Maydell]

On 31 July 2015 at 10:29, Naman patel <naman321@gmail.com> wrote:
> Can someone explain me what happens when a guest OS calls "invlpg" on say
> page swap out or a context switch? What exactly is the call flow and how
> QEMU handles this instruction?

When we see the instruction during translation, we emit code
which will
 * get the argument to invlpg (extracting it from the
relevant register, adding any constant offset required for
the addressing mode, etc)
 * make a call to helper_inlvpg().
(target-i386/translate.c has the C code that does this codegen --
search for invlpg)

Later when that generated code is run, we call the helper, which
does what it needs to do (in this case flush a page from QEMU's
TLB cache). When the call returns we'll carry on executing whatever
guest instruction comes next.

> Also is there anyway QEMU can send some data
> back to the guest OS?

INVLPG is just an x86 instruction that performs an operation;
it doesn't modify any registers or flags. So there's no way
for it to tell the guest OS anything.

-- PMM

Re: [Qemu-devel] Call Trace for QEMU functions

[Naman patel]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

On Fri, Jul 31, 2015 at 3:32 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 31 July 2015 at 10:29, Naman patel <naman321@gmail.com> wrote:
> > Can someone explain me what happens when a guest OS calls "invlpg" on say
> > page swap out or a context switch? What exactly is the call flow and how
> > QEMU handles this instruction?
>
> When we see the instruction during translation, we emit code
> which will
>
​In which function does the translation takes place?​


>  * get the argument to invlpg (extracting it from the
> relevant register, adding any constant offset required for
> the addressing mode, etc)
>
​Where exactly is it done?​


>  * make a call to helper_inlvpg().
> (target-i386/translate.c has the C code that does this codegen --
> search for invlpg)
>
​Thanks I got this function.​


>
> Later when that generated code is run, we call the helper, which
> does what it needs to do (in this case flush a page from QEMU's
> TLB cache). When the call returns we'll carry on executing whatever
> guest instruction comes next.
>
> > Also is there anyway QEMU can send some data
> > back to the guest OS?
>
> ​​
> INVLPG is just an x86 instruction that performs an operation;
> it doesn't modify any registers or flags. So there's no way
> for it to tell the guest OS anything.
>
​True that ​
​
INVLPG only invalidates a TLB entry but in general how can one send a data
structure(DS) back to guest OS from QEMU? I want to write my own function
that can send a DS back to the guest OS. Are there any similar functions
already present that sends back DS to guest? Or is it feasible?

>
> -- PMM
>


​Thanks a lot for this information. It helped a lot.

Regards,
Naman​

[-- Attachment #2: Type: text/html, Size: 3721 bytes --]