From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QygmT-0003jp-3W for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:08:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QygmS-0006ui-0M for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:08:21 -0400 Received: from mtagate3.uk.ibm.com ([194.196.100.163]:45331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QygmR-0006ub-OH for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:08:19 -0400 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p7V98H4X019518 for ; Wed, 31 Aug 2011 09:08:17 GMT Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7V98HLg1945740 for ; Wed, 31 Aug 2011 10:08:17 +0100 Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7V98GJs014465 for ; Wed, 31 Aug 2011 03:08:16 -0600 Date: Wed, 31 Aug 2011 10:08:15 +0100 From: Stefan Hajnoczi Message-ID: <20110831090815.GA2038@stefanha-thinkpad.localdomain> References: <4E5DF31A.1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5DF31A.1@redhat.com> Subject: Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , =?iso-8859-1?Q?Llu=EDs?= , qemu-devel , Dhaval Giani On Wed, Aug 31, 2011 at 11:38:50AM +0300, Avi Kivity wrote: > On 08/26/2011 10:06 PM, Blue Swirl wrote: > >Let guests inject tracepoint data via fw_cfg device. > > > > > > At least on x86, fw_cfg is pretty slow, involving multiple exits. > IMO, for kvm, even one exit per tracepoint is too high. We need to > use a shared memory transport with a way to order guest/host events > later on (by using a clock). It depends how you want to use this. If you need it for guest firmware debugging or bringing up a new target, then this approach is fine. But this is not a mechanism that is suitable for performance analysis or production tracing (the fact that the QEMU and guest software need to be built together in order to sync on event IDs is the killer). Dhaval is looking at Linux guest tracing which is suitable for performance work. This does not necessarily involve modifying QEMU. Currently he uses a hypercall but a virtio device would be possible too. The key thing is that it integrates with the host kernel tracing infrastructure so you get a unified trace instead of terminating in QEMU userspace. So I see Blue's feature as a quick starting point for people who need to debug and hack guests. It should be simple and easy to get going for QEMU developers, but is not suitable for other use. Stefan