From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qygpt-0004i9-7C for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:11:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qygps-0007Ma-6R for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:11:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qygpr-0007MP-RR for qemu-devel@nongnu.org; Wed, 31 Aug 2011 05:11:52 -0400 Message-ID: <4E5DFABF.2000007@redhat.com> Date: Wed, 31 Aug 2011 12:11:27 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E5DF31A.1@redhat.com> <20110831090815.GA2038@stefanha-thinkpad.localdomain> In-Reply-To: <20110831090815.GA2038@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Blue Swirl , =?ISO-8859-1?Q?Llu=EDs?= , qemu-devel , Dhaval Giani On 08/31/2011 12:08 PM, Stefan Hajnoczi wrote: > > > > 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. IMO a hypercall is the way to go, virtio is not entirely suitable for per-cpu work. > 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. > We should have one tracing mechanism that is useful everywhere, not fragmented functionality. -- error compiling committee.c: too many arguments to function