Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough

[Avi Kivity]

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