qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dhaval Giani
Subject: Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough
Date: Wed, 31 Aug 2011 11:01:13 -0700

On Wed, Aug 31, 2011 at 6:38 AM, Stefan Hajnoczi <address@hidden> wrote:
> 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?
>

I will try to post it soon. It will probably be untested and will not
work, but you will have the approach to look at :-)

Thanks
Dhaval



reply via email to

[Prev in Thread] Current Thread [Next in Thread]