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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Wed, Aug 31, 2011 at 10:11 AM, Avi Kivity <avi@redhat.com> wrote:
> 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.

You have a point.

Dhaval: Any update on the approach you are working on?  Do you have
public code we can look at?

Stefan