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.ben...@linaro.org> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On 30 July 2015 at 13:20, Naman patel <naman...@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 >
