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
