From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO1O7-0007Hm-Iy for qemu-devel@nongnu.org; Tue, 26 Jan 2016 06:02:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO1O2-00046k-J7 for qemu-devel@nongnu.org; Tue, 26 Jan 2016 06:02:19 -0500 Received: from mail.uni-paderborn.de ([131.234.142.9]:43887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO1O2-00046X-DB for qemu-devel@nongnu.org; Tue, 26 Jan 2016 06:02:14 -0500 References: <1452768923-13787-1-git-send-email-peer.adelt@c-lab.de> From: Bastian Koppelmann Message-ID: <56A75230.4070008@mail.uni-paderborn.de> Date: Tue, 26 Jan 2016 12:02:08 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH 0/3] (Resend) TranslationBlock annotation mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Peer Adelt Cc: Paolo Bonzini , kbastian@mail.upb.de, QEMU Developers , =?UTF-8?Q?Llu=c3=ads_Vilanova?= Hi Peter, thank you for your feedback. > (2) it feels a bit unpolished at the moment (lack of documentation, > doesn't have any existing analysis tools that produce the format that > the code reads that would make it immediately usable by an end-user) > Sure this is unpolished but we wanted to get feedback before we put too much work into it. > I think that a design that would likely get better traction here with > QEMU upstream would be one where you had tracepoints for relevant > events like "executing new TB", and some means of writing a plugin > to run code on those events, or perhaps just a post-analysis tool that > ran on the trace file. Then the code for reading XML and adding up the > relevant annotations would be confined to the plugin and wouldn't > necessarily need to be upstream at all. > We like your idea of a "plugin-api" that exposes hooks for relevant events since this is more generic than our approach. We came up with a list of relevant events for tracing: - pre-/post-execute_tb - pre-/post-translate_tb - pre-/post-interrupt (- memory access) These are the hooks that would be sufficient for our ideas for plugins. Do you have more suggestions for suitable hooks? Also, is there anything similar already in QEMU on which we could build on? > However you should take that design suggestion with a considerable > pinch of salt, as I am very much not up to speed with the current > state of our tracing infrastructure. Who would I ask for the current state of tracing? Stefan? Cheers, Bastian