From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1babgj-0005Pl-Da for qemu-devel@nongnu.org; Fri, 19 Aug 2016 00:45:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1babge-0006up-Dx for qemu-devel@nongnu.org; Fri, 19 Aug 2016 00:45:49 -0400 Received: from mail.kernel.org ([198.145.29.136]:51016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1babge-0006uj-4N for qemu-devel@nongnu.org; Fri, 19 Aug 2016 00:45:44 -0400 Date: Fri, 19 Aug 2016 13:45:31 +0900 From: Masami Hiramatsu Message-Id: <20160819134531.6e7c4099e52ba115413ee540@kernel.org> In-Reply-To: <20160818093711.6f77c30b@redhat.com> References: <147041636348.2523.2954972609232949598.stgit@fimbulvetr.bsc.es> <20160818105424.GD4850@stefanha-x1.localdomain> <20160818093711.6f77c30b@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Stefan Hajnoczi , =?UTF-8?B?TGx1w61z?= Vilanova , qemu-devel@nongnu.org, Stefan Hajnoczi , Steven Rostedt , Masami Hiramatsu , lttng-dev@lists.lttng.org On Thu, 18 Aug 2016 09:37:11 -0400 Luiz Capitulino wrote: > On Thu, 18 Aug 2016 11:54:24 +0100 > Stefan Hajnoczi wrote: >=20 > > On Fri, Aug 05, 2016 at 06:59:23PM +0200, Llu=C3=ADs Vilanova wrote: > > > The hypertrace channel allows guest code to emit events in QEMU (th= e host) using > > > its tracing infrastructure (see "docs/trace.txt"). This works in bo= th 'system' > > > and 'user' modes. That is, hypertrace is to tracing, what hypercall= s are to > > > system calls. > > >=20 > > > You can use this to emit an event on both guest and QEMU (host) tra= ces to easily > > > synchronize or correlate them. You could also modify you guest's tr= acing system > > > to emit all events through the hypertrace channel, providing a unif= ied and fully > > > synchronized trace log. Another use case is timing the performance = of guest code > > > when optimizing TCG (QEMU traces have a timestamp). > > >=20 > > > See first commit for a full description. =20 >=20 > I hate the be the one asking the stupid questions, but what's > the problem this series solves? What are the use-cases? Why > existing solutions don't solve this problem? How does this > compares to existing solutions? >=20 > > This tracing approach has a high performance overhead, particularly f= or > > SMP guests where each trace event requires writing to the global cont= rol > > register. All CPUs will be hammering this register (heavyweight vmex= it) > > for each trace event. That reminds me xenprobes. https://www.usenix.org/legacy/event/usenix07/tech/full_papers/quynh/quynh= .pdf The paper also tried to implement kprobe-like feature for tracing events = in guest. Synchronous tracing maybe easy to read the raw trace data, but cau= se big slowdown. Moreover, we can merge and synchronize the data easily afte= r traced. > >=20 > > I think the folks CCed on this email all take an asynchronous approac= h > > to avoid this performance overhead. Synchronous means taking a VM ex= it > > for every event. Asynchronous means writing trace data to a buffer a= nd > > later interleaving guest data with host trace data. > >=20 > > LTTng Userspace Tracer is an example of the asynchronous approach. T= he > > trace data buffers are in shared memory. The LTTng process can grab > > buffers at appropriate times. > >=20 > > The ftrace virtio-serial approach has been to splice() the ftrace > > buffers, resulting in efficient I/O. >=20 > Yes. However, note that the virtio-serial device is only used to > transfer the tracing data to the host. It has no role in the > tracing process. Also, it's not required. I've been using the > networking and it works OK as long as your tracing data is not big. Right, the no-copy virtio-serial is for reducing the overhead as small as possible but it also requires a special programs in both of guest and hos= t. (since it uses unix domain socket to transfer data without copy) In normal case, you can just trace it as like as tracing on a remote mach= ine via network. That's more scalable and flexible.=20 > > Steven is working on a host/guest solution for trace-cmd. It is also > > asynchronous. No new paravirt hardware is needed and it makes me won= der > > whether the hypertrace PCI device is trying to solve the problem at t= he > > wrong layer. Thanks Steven to continue that! Regards, > >=20 > > If you want to play around with asynchronous tracing, you could start > > with trace/simple.c. It has a trace buffer that is asynchronously > > written out to file by a dedicated "writer" thread. > >=20 > > The one case where hypertrace makes sense to me is for -user tracing. > > There QEMU can efficiently interleave guest and QEMU traces, although= as > > mentioned in the patch, I don't think the SIGSEGV approach should be > > used. > >=20 > > I suggest stripping this series down to focus on -user. Synchronous > > tracing is not a good approach for -system emulation. > >=20 > > Stefan >=20 --=20 Masami Hiramatsu