[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthro
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough |
Date: |
Wed, 31 Aug 2011 14:38:21 +0100 |
On Wed, Aug 31, 2011 at 10:11 AM, Avi Kivity <address@hidden> 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