[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: |
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