On Fri, Feb 02, 2018 at 03:53:45PM +0000, Peter Maydell wrote: > On 2 February 2018 at 10:08, 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. > > I think at the moment the status is that we're still discussing > what the trace plugin API should be... there are some mailing
s/trace plugin API/instrumentation plugin API/ > list threads on the subject from I think last year some time. The point of the instrumentation plugin API is for online analysis (stuff that cannot be post-processed offline) with the ability for the plugin to control QEMU (e.g. affect translation during a run). That is not necessary for Nesrine's use case. I see two main requirements in Nesrine's use case: 1. Instruction flow, memory access, and task switch trace. This doesn't exist today and requires adding new trace events. 2. An external interface for processing traces. There seems to be a requirement for doing it online and not by post-processing trace files. Therefore I suggested looking into LTTng UST, which has an efficient interface and libraries for tracing processes. I think no QEMU changes are necessary here. Stefan
signature.asc
Description: PGP signature
