From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOmor-0004Ox-Hq for qemu-devel@nongnu.org; Thu, 28 Jan 2016 08:41:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOmom-0004bo-RA for qemu-devel@nongnu.org; Thu, 28 Jan 2016 08:41:05 -0500 Received: from mail.uni-paderborn.de ([131.234.142.9]:41293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOmom-0004bP-Jv for qemu-devel@nongnu.org; Thu, 28 Jan 2016 08:41:00 -0500 References: <1452768923-13787-1-git-send-email-peer.adelt@c-lab.de> <56A75230.4070008@mail.uni-paderborn.de> <87egd2kg4m.fsf@fimbulvetr.bsc.es> From: Bastian Koppelmann Message-ID: <56AA1A67.7030609@mail.uni-paderborn.de> Date: Thu, 28 Jan 2016 14:40:55 +0100 MIME-Version: 1.0 In-Reply-To: <87egd2kg4m.fsf@fimbulvetr.bsc.es> Content-Type: text/plain; charset=windows-1252 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: =?UTF-8?Q?Llu=c3=ads_Vilanova?= Cc: Peter Maydell , Paolo Bonzini , kbastian@mail.upb.de, QEMU Developers , Peer Adelt Hi Lluis, On 01/27/2016 07:54 PM, Lluís Vilanova wrote: > There is this modified version I wrote [1], which precisely provides a plugin > infrastructure to attach callbacks into guest code events (a binary > instrumentation framework based on QEMU). At the time, the discussion resolved > that a full code instrumentation interface for plugins was too much code that > regular QEMU users & developers would not care about, easily leading to bitrot. > This is too bad but looking at the discussion back then the argumentation is reasonable since an instrumentation API would and should touch everything in QEMU. > Instead, the list resolved (AFAIU) that it would be better to mainstream support > for guest code events, and make instrumentation an unofficial extension. I've > been (slowly) working to separate both pieces, making instrumentation a QEMU > patch that can be easily maintained out of tree. > > The last patch series I sent sets the final stone on the core infrastructure for > the mainline part, just missing the patches I have queued to start adding guest > code trace events. Can you give me the name of the series. > > So, I'd say that such support is on the list of current developments (at least > mine, specially now that I have a bit more time for it). But getting the core > infrastructure mainlined takes some time to ensure it makes sense and can be > easily maintained and be generally usefull to vanilla QEMU. > For us such a API would make a lot of sense and there is no benefit for us to do our own API. Would it make sense for you if we helped you? Cheers, Bastian