[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] trace: timestamps, core IDs, and file creation
From: |
Lluís Vilanova |
Subject: |
Re: [Qemu-devel] trace: timestamps, core IDs, and file creation |
Date: |
Mon, 08 Feb 2016 17:29:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Stefan Hajnoczi writes:
> On Wed, Jan 13, 2016 at 03:13:02PM -0800, Hollis Blanchard wrote:
>> Hi Stefan, I've been starting to use qemu tracing and found it quite useful.
>> I have a couple comments about the trace events in general:
> Sorry for the late reply.
>> The event timestamps are host time (get_clock()). I'm correlating qemu
>> events with other logs (using icount), so host time is unhelpful. Could we
>> use cpu_get_clock() instead? (Trace events are used in other tools like
>> qemu-io, where guest time doesn't exist, and there we could continue to use
>> get_clock().)
> It must be possible to trace code while the guest CPUs are stopped, so
> cpu_get_clock() on own breaks existing users.
> If the CPU clock is more convenient for you, perhaps you can add an
> option to use that clocksource?
Hmmmm, what about abusing the "vcpu" event property I sent to automatically emit
the vCPU icount? We could make that a compile-time option. This also makes me
think that the print format for the vCPU can be auto-generated by tracetool (it
must now be set explicitly), so that what's printed can be easily interchanged.
We can make that a follow-up series.
>> When trying to understand multi-core guest behavior, it's pretty important
>> to know which core is performing the traced action (e.g. MMIO). Would it
>> make sense to automatically embed the core index, like the timestamp, or do
>> you think it should be encoded in each individual tracepoint?
> I think that Lluís has some of this stuff automated in his TCG tracing
> work. He has added special trace event types for TCG that can be
> planted at code generation time as well as TB execution time. They can
> include the vcpu number automatically IIRC.
Yup, that's the last series I sent, which hasn't been reviewed yet:
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05996.html
If any event (including outside tcg code) has a pointer to the "guilty" vCPU,
support for showing the vCPU can be easily added.
> Regarding I/O emulation, we have to be careful because architecturally
> some types of devices (e.g. PCI devices) don't have the concept of which
> core is performing an action. QEMU takes advantage of that with
> ioeventfd where a lightweight vmexit simply marks an eventfd file
> descriptor readable in the kernel and quickly returns back to vcpu
> execution. Another QEMU thread monitors the eventfd and processes the
> notification and there is no concept of the current vcpu at that point.
> It might be easiest to include the vcpu id in the trace event explicitly
> for now.
See the two responses above.
Cheers,
Lluis