Hello Mr. Stefan, Thank you for your response. To answer your question : the trace solution should be architecture independent.This is the best for us. We aim to test it at least for ARM/ARM64 , x86 and x64 architectures. But even if there will be some differences , we can accept it.
Regards, On Fri, Feb 2, 2018 at 11:08 AM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > On Thu, Feb 01, 2018 at 04:30:10PM +0100, Nesrine Zouari wrote: > > I am a computer engineering student and I am actually working on my > > graduation project at Lauterbach company. The project is about Qemu Trace > > and as a future I would like to contribute this work to the main line. > > > > My project is divided into two parts: > > > > 1/ Collecting the Guest trace data : The trace solution should be able to > > provide: > > > > a/ Instruction flow Trace > > > > b/ Memory read/write access > > > > c/ Time Stamps. > > > > d/ For tracing rich operating systems that are using MMU, we > > additionally need to trace the task switches. > > Lluìs has done the most instrumentation work in qemu.git and can explain > the current status. > > The focus in QEMU is more on functional simulation than on low-level > instrumentation. Therefore the instrumentation facilities aren't very > rich. Code changes will be required to get the information you need. > In order to be suitable for upstream they should not be too invasive or > impact performance significantly. > > Which CPU architecture are you targeting? > > > 2/ Sending the collected data to a third party tool for analysis. > > > > My question is about the first part. I would like to know, which trace > > backend that better fit my use case. > > LTTng UST has the highest performance tracing interface. It uses shared > memory to efficiently export trace data to a collector or analysis > process. > > It is probably not necessary to invent your own tracer or interface for > capturing trace data. I suggest looking into LTTng UST and trying it > out. > > The basic idea would be: > > 1. Add missing trace events to QEMU > 2. Build with ./configure --enable-trace-backend=ust && make > 3. Use LTTng tools or write your own collector using the LTTng libraries > 4. Enable the trace events that you need for instruction flow, memory > access, and task switching. > > The QEMU code changes involved would be changes to trace-events and > placing those trace events into TCG and/or memory API code to record the > necessary information. > > Stefan > -- ----------------------------------------------------------------------------------------- Nesrine ZOUARI Computer Engineering Student Department of Computer Engineering and Applied Mathematics National Engineering School of Sfax (ENIS) University of Sfax-Tunisia Tel: +216 52 620 475