* [PATCH V3 0/1] kvm: Output TSC offset @ 2013-06-12 7:43 Yoshihiro YUNOMAE 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Yoshihiro YUNOMAE @ 2013-06-12 7:43 UTC (permalink / raw) To: Marcelo Tosatti, linux-kernel, Gleb Natapov Cc: David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner Hi All, I'd like to propose a patch which adds a tracepoint at write_tsc_offset for tracing guests TSC offset changes. It is required for sorting the trace data of a guest and the host in chronological order. In a virtualization environment, it is difficult to analyze performance problems, such as a delay of I/O request on a guest. This is because multiple guests operate on the host. One of approaches for solving such kind of problems is to sort trace data of guests and the host in chronological order. Raw TSC can be chosen as a timestamp of ftrace. I think TSC is useful for merging trace data in chronological order by two reasons. One of the reasons is that guests can directly read raw TSC from the CPU using rdtsc operation. This means that raw TSC value is not software clock like sched_clock, so we don't need to consider about how the timestamp is calculated. The other is that TSC of recent x86 CPUs is constantly incremented. This means that we don't need to worry about pace of the timestamp. Therefore, choosing TSC as a timestamp for tracing is reasonable to integrate trace data of guests and a host. Here, we need to consider about just one matter for using TSC on guests. TSC value on a guest is always the host TSC plus the guest's "TSC offset". In other words, to merge trace data using TSC as timestamp in chronological order, we need to consider TSC offset of the guest. However, only the host kernel can read the TSC offset from VMCS and TSC offset is not output in anywhere now. In other words, tools in userland cannot get the TSC offset value, so we cannot merge trace data of guest and the host in chronological order. Therefore, I think the TSC offset should be exported for userland tools. In this patch, TSC offset is exported by the tracepoint kvm_write_tsc_offset on the host. TSC offset events will be very rare event because guests may seldom execute write_tsc. So if we enable this event for a normal buffer of ftrace, the events will be overwritten by other events. For a recent linux kernel, a multiple buffer function is available. So, I recommend to enable this event for a sub buffer of ftrace. <Example> We assume that wakeup-latency for a command is big on a guest. Normally we will use ftrace's wakeup-latency tracer or event tracer on the guest, but we may not be able to solve this problem. This is because guests often exit to the host for several reasons. In the next, we will use TSC as ftrace's timestamp and record the trace data on the guest and the host. Then, we get following data: /* guest data */ comm-3826 [000] d...49836825726903: sched_wakeup: [detail] comm-3826 [000] d...49836832225344: sched_switch: [detail] /* host data */ qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] Since TSC offset is not considered, these data cannot be merged. If this trace data is shown like as follows, we will be able to understand the reason: qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] comm-3826 [000] d.h.49836825726903: sched_wakeup: [detail] <= qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] comm-3826 [000] d...49836832225344: sched_switch: [detail] <= qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] In this case, we can understand wakeup-latency was big due to exit to host twice. Getting this data sorted in chronological order is our goal. To merge the data like previous pattern, we apply this patch. Then, we can get TSC offset of the guest as follows: # cat /sys/kernel/debug/tracing/instances/tsc_offset/trace .. d...4300151845072: kvm_write_tsc_offset: vcpu=0 prev=0 next=18446739773557710924 ^ ^^^^^^^^^^^^^^^^^^^^ We use this TSC offset value to a merge script and obtain the following data: $ ./trace-merge.pl -g guest_data -h host_data -t 18446739773557710924 h qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] g comm-3826 [000] d.h.50550079226331: sched_wakeup: [detail] <= h qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] h qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] g comm-3826 [000] d...50550079279266: sched_switch: [detail] <= h qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] | \----guest/host In this summary, I suggest the patch which TSC offset for each guest can be output on the host. As one example, I will send a merge tool. This tool assumes the guest doesn't execute write_tsc. Changes in V2: - Use tracepoint for outputting TSC offset value instead of printk() [1/1] Changes in V3: - Add tracepoint in svm.c [1/1] - Record vcpu_id [1/1] - Change "previous=" to "prev=" in output result [1/1] Thanks! --- Yoshihiro YUNOMAE (1): kvm: Add a tracepoint write_tsc_offset arch/x86/kvm/svm.c | 10 +++++++++- arch/x86/kvm/trace.h | 21 +++++++++++++++++++++ arch/x86/kvm/vmx.c | 7 ++++++- arch/x86/kvm/x86.c | 1 + 4 files changed, 37 insertions(+), 2 deletions(-) -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae.ez@hitachi.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset 2013-06-12 7:43 [PATCH V3 0/1] kvm: Output TSC offset Yoshihiro YUNOMAE @ 2013-06-12 7:43 ` Yoshihiro YUNOMAE 2013-06-12 22:44 ` Marcelo Tosatti 2013-06-24 15:02 ` Paolo Bonzini 2013-06-12 7:46 ` [EXAMPLE] tools: a tool for merging trace data of a guest and a host Yoshihiro YUNOMAE 2013-06-23 7:58 ` [PATCH V3 0/1] kvm: Output TSC offset Gleb Natapov 2 siblings, 2 replies; 9+ messages in thread From: Yoshihiro YUNOMAE @ 2013-06-12 7:43 UTC (permalink / raw) To: Marcelo Tosatti, linux-kernel, Gleb Natapov Cc: David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner, Joerg Roedel Add a tracepoint write_tsc_offset for tracing TSC offset change. We want to merge ftrace's trace data of guest OSs and the host OS using TSC for timestamp in chronological order. We need "TSC offset" values for each guest when merge those because the TSC value on a guest is always the host TSC plus guest's TSC offset. If we get the TSC offset values, we can calculate the host TSC value for each guest events from the TSC offset and the event TSC value. The host TSC values of the guest events are used when we want to merge trace data of guests and the host in chronological order. (Note: the trace_clock of both the host and the guest must be set x86-tsc in this case) This tracepoint also records vcpu_id which can be used to merge trace data for SMP guests. A merge tool will read TSC offset for each vcpu, then the tool converts guest TSC values to host TSC values for each vcpu. TSC offset is stored in the VMCS by vmx_write_tsc_offset() or vmx_adjust_tsc_offset(). KVM executes the former function when a guest boots. The latter function is executed when kvm clock is updated. Only host can read TSC offset value from VMCS, so a host needs to output TSC offset value when TSC offset is changed. Since the TSC offset is not often changed, it could be overwritten by other frequent events while tracing. To avoid that, I recommend to use a special instance for getting this event: 1. set a instance before booting a guest # cd /sys/kernel/debug/tracing/instances # mkdir tsc_offset # cd tsc_offset # echo x86-tsc > trace_clock # echo 1 > events/kvm/kvm_write_tsc_offset/enable 2. boot a guest Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Gleb Natapov <gleb@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> --- arch/x86/kvm/svm.c | 10 +++++++++- arch/x86/kvm/trace.h | 21 +++++++++++++++++++++ arch/x86/kvm/vmx.c | 7 ++++++- arch/x86/kvm/x86.c | 1 + 4 files changed, 37 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index a14a6ea..c0bc803 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1026,7 +1026,10 @@ static void svm_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) g_tsc_offset = svm->vmcb->control.tsc_offset - svm->nested.hsave->control.tsc_offset; svm->nested.hsave->control.tsc_offset = offset; - } + } else + trace_kvm_write_tsc_offset(vcpu->vcpu_id, + svm->vmcb->control.tsc_offset, + offset); svm->vmcb->control.tsc_offset = offset + g_tsc_offset; @@ -1044,6 +1047,11 @@ static void svm_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool ho svm->vmcb->control.tsc_offset += adjustment; if (is_guest_mode(vcpu)) svm->nested.hsave->control.tsc_offset += adjustment; + else + trace_kvm_write_tsc_offset(vcpu->vcpu_id, + svm->vmcb->control.tsc_offset - adjustment, + svm->vmcb->control.tsc_offset); + mark_dirty(svm->vmcb, VMCB_INTERCEPTS); } diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index fe5e00e..6c82cf1 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -815,6 +815,27 @@ TRACE_EVENT(kvm_track_tsc, __print_symbolic(__entry->host_clock, host_clocks)) ); +TRACE_EVENT(kvm_write_tsc_offset, + TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, + __u64 next_tsc_offset), + TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), + + TP_STRUCT__entry( + __field( unsigned int, vcpu_id ) + __field( __u64, previous_tsc_offset ) + __field( __u64, next_tsc_offset ) + ), + + TP_fast_assign( + __entry->vcpu_id = vcpu_id; + __entry->previous_tsc_offset = previous_tsc_offset; + __entry->next_tsc_offset = next_tsc_offset; + ), + + TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, + __entry->previous_tsc_offset, __entry->next_tsc_offset) +); + #endif /* CONFIG_X86_64 */ #endif /* _TRACE_KVM_H */ diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 25a791e..eb11856 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2096,6 +2096,8 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING) ? vmcs12->tsc_offset : 0)); } else { + trace_kvm_write_tsc_offset(vcpu->vcpu_id, + vmcs_read64(TSC_OFFSET), offset); vmcs_write64(TSC_OFFSET, offset); } } @@ -2103,11 +2105,14 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) static void vmx_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool host) { u64 offset = vmcs_read64(TSC_OFFSET); + vmcs_write64(TSC_OFFSET, offset + adjustment); if (is_guest_mode(vcpu)) { /* Even when running L2, the adjustment needs to apply to L1 */ to_vmx(vcpu)->nested.vmcs01_tsc_offset += adjustment; - } + } else + trace_kvm_write_tsc_offset(vcpu->vcpu_id, offset, + offset + adjustment); } static u64 vmx_compute_tsc_offset(struct kvm_vcpu *vcpu, u64 target_tsc) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 05a8b1a..c942a0c 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7264,3 +7264,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intr_vmexit); EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_invlpga); EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_skinit); EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intercepts); +EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_write_tsc_offset); ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE @ 2013-06-12 22:44 ` Marcelo Tosatti 2013-06-24 15:02 ` Paolo Bonzini 1 sibling, 0 replies; 9+ messages in thread From: Marcelo Tosatti @ 2013-06-12 22:44 UTC (permalink / raw) To: Yoshihiro YUNOMAE Cc: linux-kernel, Gleb Natapov, David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner, Joerg Roedel On Wed, Jun 12, 2013 at 04:43:44PM +0900, Yoshihiro YUNOMAE wrote: > Add a tracepoint write_tsc_offset for tracing TSC offset change. > We want to merge ftrace's trace data of guest OSs and the host OS using > TSC for timestamp in chronological order. We need "TSC offset" values for > each guest when merge those because the TSC value on a guest is always the > host TSC plus guest's TSC offset. If we get the TSC offset values, we can > calculate the host TSC value for each guest events from the TSC offset and > the event TSC value. The host TSC values of the guest events are used when we > want to merge trace data of guests and the host in chronological order. > (Note: the trace_clock of both the host and the guest must be set x86-tsc in > this case) > > This tracepoint also records vcpu_id which can be used to merge trace data for > SMP guests. A merge tool will read TSC offset for each vcpu, then the tool > converts guest TSC values to host TSC values for each vcpu. > > TSC offset is stored in the VMCS by vmx_write_tsc_offset() or > vmx_adjust_tsc_offset(). KVM executes the former function when a guest boots. > The latter function is executed when kvm clock is updated. Only host can read > TSC offset value from VMCS, so a host needs to output TSC offset value > when TSC offset is changed. > > Since the TSC offset is not often changed, it could be overwritten by other > frequent events while tracing. To avoid that, I recommend to use a special > instance for getting this event: > > 1. set a instance before booting a guest > # cd /sys/kernel/debug/tracing/instances > # mkdir tsc_offset > # cd tsc_offset > # echo x86-tsc > trace_clock > # echo 1 > events/kvm/kvm_write_tsc_offset/enable > > 2. boot a guest > > Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> > Cc: Joerg Roedel <joro@8bytes.org> > Cc: Marcelo Tosatti <mtosatti@redhat.com> > Cc: Gleb Natapov <gleb@redhat.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > --- > arch/x86/kvm/svm.c | 10 +++++++++- > arch/x86/kvm/trace.h | 21 +++++++++++++++++++++ > arch/x86/kvm/vmx.c | 7 ++++++- > arch/x86/kvm/x86.c | 1 + > 4 files changed, 37 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index a14a6ea..c0bc803 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -1026,7 +1026,10 @@ static void svm_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > g_tsc_offset = svm->vmcb->control.tsc_offset - > svm->nested.hsave->control.tsc_offset; > svm->nested.hsave->control.tsc_offset = offset; > - } > + } else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + svm->vmcb->control.tsc_offset, > + offset); > > svm->vmcb->control.tsc_offset = offset + g_tsc_offset; > > @@ -1044,6 +1047,11 @@ static void svm_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool ho > svm->vmcb->control.tsc_offset += adjustment; > if (is_guest_mode(vcpu)) > svm->nested.hsave->control.tsc_offset += adjustment; > + else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + svm->vmcb->control.tsc_offset - adjustment, > + svm->vmcb->control.tsc_offset); > + > mark_dirty(svm->vmcb, VMCB_INTERCEPTS); > } > > diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h > index fe5e00e..6c82cf1 100644 > --- a/arch/x86/kvm/trace.h > +++ b/arch/x86/kvm/trace.h > @@ -815,6 +815,27 @@ TRACE_EVENT(kvm_track_tsc, > __print_symbolic(__entry->host_clock, host_clocks)) > ); > > +TRACE_EVENT(kvm_write_tsc_offset, > + TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > + __u64 next_tsc_offset), > + TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > + > + TP_STRUCT__entry( > + __field( unsigned int, vcpu_id ) > + __field( __u64, previous_tsc_offset ) > + __field( __u64, next_tsc_offset ) > + ), > + > + TP_fast_assign( > + __entry->vcpu_id = vcpu_id; > + __entry->previous_tsc_offset = previous_tsc_offset; > + __entry->next_tsc_offset = next_tsc_offset; > + ), > + > + TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > + __entry->previous_tsc_offset, __entry->next_tsc_offset) > +); > + > #endif /* CONFIG_X86_64 */ > > #endif /* _TRACE_KVM_H */ > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 25a791e..eb11856 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -2096,6 +2096,8 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING) ? > vmcs12->tsc_offset : 0)); > } else { > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + vmcs_read64(TSC_OFFSET), offset); > vmcs_write64(TSC_OFFSET, offset); > } > } > @@ -2103,11 +2105,14 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > static void vmx_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool host) > { > u64 offset = vmcs_read64(TSC_OFFSET); > + > vmcs_write64(TSC_OFFSET, offset + adjustment); > if (is_guest_mode(vcpu)) { > /* Even when running L2, the adjustment needs to apply to L1 */ > to_vmx(vcpu)->nested.vmcs01_tsc_offset += adjustment; > - } > + } else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, offset, > + offset + adjustment); > } > > static u64 vmx_compute_tsc_offset(struct kvm_vcpu *vcpu, u64 target_tsc) > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 05a8b1a..c942a0c 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7264,3 +7264,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intr_vmexit); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_invlpga); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_skinit); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intercepts); > +EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_write_tsc_offset); ACK ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE 2013-06-12 22:44 ` Marcelo Tosatti @ 2013-06-24 15:02 ` Paolo Bonzini 1 sibling, 0 replies; 9+ messages in thread From: Paolo Bonzini @ 2013-06-24 15:02 UTC (permalink / raw) To: Yoshihiro YUNOMAE Cc: Marcelo Tosatti, linux-kernel, Gleb Natapov, David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner, Joerg Roedel Il 12/06/2013 09:43, Yoshihiro YUNOMAE ha scritto: > Add a tracepoint write_tsc_offset for tracing TSC offset change. > We want to merge ftrace's trace data of guest OSs and the host OS using > TSC for timestamp in chronological order. We need "TSC offset" values for > each guest when merge those because the TSC value on a guest is always the > host TSC plus guest's TSC offset. If we get the TSC offset values, we can > calculate the host TSC value for each guest events from the TSC offset and > the event TSC value. The host TSC values of the guest events are used when we > want to merge trace data of guests and the host in chronological order. > (Note: the trace_clock of both the host and the guest must be set x86-tsc in > this case) > > This tracepoint also records vcpu_id which can be used to merge trace data for > SMP guests. A merge tool will read TSC offset for each vcpu, then the tool > converts guest TSC values to host TSC values for each vcpu. > > TSC offset is stored in the VMCS by vmx_write_tsc_offset() or > vmx_adjust_tsc_offset(). KVM executes the former function when a guest boots. > The latter function is executed when kvm clock is updated. Only host can read > TSC offset value from VMCS, so a host needs to output TSC offset value > when TSC offset is changed. > > Since the TSC offset is not often changed, it could be overwritten by other > frequent events while tracing. To avoid that, I recommend to use a special > instance for getting this event: > > 1. set a instance before booting a guest > # cd /sys/kernel/debug/tracing/instances > # mkdir tsc_offset > # cd tsc_offset > # echo x86-tsc > trace_clock > # echo 1 > events/kvm/kvm_write_tsc_offset/enable > > 2. boot a guest > > Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> > Cc: Joerg Roedel <joro@8bytes.org> > Cc: Marcelo Tosatti <mtosatti@redhat.com> > Cc: Gleb Natapov <gleb@redhat.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > --- > arch/x86/kvm/svm.c | 10 +++++++++- > arch/x86/kvm/trace.h | 21 +++++++++++++++++++++ > arch/x86/kvm/vmx.c | 7 ++++++- > arch/x86/kvm/x86.c | 1 + > 4 files changed, 37 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index a14a6ea..c0bc803 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -1026,7 +1026,10 @@ static void svm_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > g_tsc_offset = svm->vmcb->control.tsc_offset - > svm->nested.hsave->control.tsc_offset; > svm->nested.hsave->control.tsc_offset = offset; > - } > + } else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + svm->vmcb->control.tsc_offset, > + offset); > > svm->vmcb->control.tsc_offset = offset + g_tsc_offset; > > @@ -1044,6 +1047,11 @@ static void svm_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool ho > svm->vmcb->control.tsc_offset += adjustment; > if (is_guest_mode(vcpu)) > svm->nested.hsave->control.tsc_offset += adjustment; > + else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + svm->vmcb->control.tsc_offset - adjustment, > + svm->vmcb->control.tsc_offset); > + > mark_dirty(svm->vmcb, VMCB_INTERCEPTS); > } > > diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h > index fe5e00e..6c82cf1 100644 > --- a/arch/x86/kvm/trace.h > +++ b/arch/x86/kvm/trace.h > @@ -815,6 +815,27 @@ TRACE_EVENT(kvm_track_tsc, > __print_symbolic(__entry->host_clock, host_clocks)) > ); > > +TRACE_EVENT(kvm_write_tsc_offset, > + TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > + __u64 next_tsc_offset), > + TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > + > + TP_STRUCT__entry( > + __field( unsigned int, vcpu_id ) > + __field( __u64, previous_tsc_offset ) > + __field( __u64, next_tsc_offset ) > + ), > + > + TP_fast_assign( > + __entry->vcpu_id = vcpu_id; > + __entry->previous_tsc_offset = previous_tsc_offset; > + __entry->next_tsc_offset = next_tsc_offset; > + ), > + > + TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > + __entry->previous_tsc_offset, __entry->next_tsc_offset) > +); > + > #endif /* CONFIG_X86_64 */ > > #endif /* _TRACE_KVM_H */ > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 25a791e..eb11856 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -2096,6 +2096,8 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING) ? > vmcs12->tsc_offset : 0)); > } else { > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, > + vmcs_read64(TSC_OFFSET), offset); > vmcs_write64(TSC_OFFSET, offset); > } > } > @@ -2103,11 +2105,14 @@ static void vmx_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > static void vmx_adjust_tsc_offset(struct kvm_vcpu *vcpu, s64 adjustment, bool host) > { > u64 offset = vmcs_read64(TSC_OFFSET); > + > vmcs_write64(TSC_OFFSET, offset + adjustment); > if (is_guest_mode(vcpu)) { > /* Even when running L2, the adjustment needs to apply to L1 */ > to_vmx(vcpu)->nested.vmcs01_tsc_offset += adjustment; > - } > + } else > + trace_kvm_write_tsc_offset(vcpu->vcpu_id, offset, > + offset + adjustment); > } > > static u64 vmx_compute_tsc_offset(struct kvm_vcpu *vcpu, u64 target_tsc) > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 05a8b1a..c942a0c 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7264,3 +7264,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intr_vmexit); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_invlpga); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_skinit); > EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_intercepts); > +EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_write_tsc_offset); > Looks good for 3.11. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [EXAMPLE] tools: a tool for merging trace data of a guest and a host 2013-06-12 7:43 [PATCH V3 0/1] kvm: Output TSC offset Yoshihiro YUNOMAE 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE @ 2013-06-12 7:46 ` Yoshihiro YUNOMAE 2013-06-23 7:58 ` [PATCH V3 0/1] kvm: Output TSC offset Gleb Natapov 2 siblings, 0 replies; 9+ messages in thread From: Yoshihiro YUNOMAE @ 2013-06-12 7:46 UTC (permalink / raw) To: Marcelo Tosatti, linux-kernel, Gleb Natapov Cc: David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner [-- Attachment #1: Type: text/plain, Size: 2567 bytes --] This tool merges trace data of a guest and a host in chronological order. Restrictions of this tool is as follows: - one guest (not for multiple guests) - stable TSC (not backward TSC) - synchronized TSC - unchanged TSC offset (the guest does not execute write_TSC) - How to use 1. [host] Enable kvm_write_tsc_offset before booting a guest # cd /sys/kernel/debug/tracing/instances # mkdir tsc_offset # cd tsc_offset # echo x86-tsc > trace_clock # echo 1 > events/kvm/kvm_write_tsc_offset/enable 2. [host] Enable events you want Note: I recommend to enable kvm_exit/entry events. # cd /sys/kernel/debug/tracing # echo kvm_entry >> set_event # echo kvm_exit >> set_event # [snip] # echo x86-tsc > trace_clock 3. [host] Boot the guest 4. [guest] Enable events you want # cd /sys/kernel/debug/tracing # echo sched_wakeup >> set_event # echo sched_switch >> set_event # [snip] # echo x86-tsc > trace_clock 5. [guest] Run programs 6. [guest/host] Get trace data # echo 0 > tracing_on # cat trace > /home/yourdir/log/guest_trace.txt (for the guest) (cat trace > /home/yourdir/log/host_trace.txt (for the host)) # scp [host_IP]:/home/yourdir/log/guest_trace.txt (only for the guest) 7. [host] Get next TSC offset # cat /sys/kernel/debug/tracing/instances/tsc_offset/trace qemu-kvm-22089 [000] d...4300151845072: kvm_write_tsc_offset: vcpu=0 prev=0 next=18446739773557710924 8. [host] Run this tool with the next TSC offset for -t option. $ ./trace-merge.pl -g ~/log/guest_trace.txt -h ~/log/host_trace.txt \ -t 18446739773557710924 h qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] g comm-3826 [000] d.h.50550079226331: sched_wakeup: [detail] h qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] h qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] g comm-3826 [000] d...50550079279266: sched_switch: [detail] h qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] h qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] | \----guest/host Thanks, -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae.ez@hitachi.com [-- Attachment #2: trace-merge.pl --] [-- Type: text/plain, Size: 2402 bytes --] #!/usr/bin/perl # # Tool for merging and sorting trace data of a guest and host # # Created by Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> # # - How to use # ./trace-merge.pl <-h host_data -g guest_data -t tsc_offset_value> # use strict; use bigint; use warnings; use Getopt::Long qw(:config posix_default no_ignore_case); my @merged_data = (); my @sorted_data = (); my ($opt_host, $opt_guest, $opt_offset); GetOptions( "host_data|h=s" => \$opt_host, "guest_data|g=s"=> \$opt_guest, "tsc_offset|t=i"=> \$opt_offset ); my $tsc_offset = 0; my $MASK64 = (1 << 64) - 1; &get_tsc_offset(); &read_all_data(); sub read_all_data { my $h_tsc = 0; my $g_comm = ""; my $g_tsc = 0; my $g_event = ""; my $h_line = ""; my $g_line = ""; open HOST_DATA, "<", $opt_host or die "Cannot open host file: $!"; open GUEST_DATA, "<", $opt_guest or die "Cannot open guest file: $!"; # skip header information of trace files while (!$h_tsc) { $h_line = <HOST_DATA>; if ($h_line =~ /\[[0-9]+\]\s.{4}\s([0-9]+):/) { $h_tsc = $1; } } # skip header information of trace files while (!$g_tsc) { $g_line = <GUEST_DATA>; if ($g_line =~ /^(.+\[[0-9]+\]\s.{4}\s)([0-9]+)(:.+)/) { $g_comm = $1; $g_tsc = ($2 - $tsc_offset) & $MASK64; $g_event = $3; } } # sort trace data by tsc while ($h_line) { if ($h_tsc < $g_tsc) { print "h $h_line"; $h_line = <HOST_DATA>; if (!$h_line) { last; } if ($h_line =~ /\[[0-9]+\]\s.{4}\s([0-9]+):/) { $h_tsc = $1; } } else { print "g $g_comm$g_tsc$g_event\n"; $g_line = <GUEST_DATA>; if (!$g_line) { last; } if ($g_line =~ /^(.+\[[0-9]+\]\s.{4}\s)([0-9]+)(:.+)/) { $g_comm = $1; $g_tsc = ($2 - $tsc_offset) & $MASK64; $g_event = $3; } } } #flush host data while ($h_line) { print "h $h_line"; $h_line = <HOST_DATA>; if (!$h_line) { last; } } #flush guest data while ($g_line) { print "g $g_comm$g_tsc$g_event\n"; $g_line = <GUEST_DATA>; if (!$g_line) { last; } if ($g_line =~ /^(.+\[[0-9]+\]\s.{4}\s)([0-9]+)(:.+)/) { $g_comm = $1; $g_tsc = ($2 - $tsc_offset) & $MASK64; $g_event = $3; } } close HOST_DATA; close GUEST_DATA; } sub get_tsc_offset { if (!$opt_offset) { $tsc_offset = 0; } else { $tsc_offset = &convert_tscoffset($opt_offset); } } sub convert_tscoffset { my $offset = shift; return $offset - (1 << 64); } ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 0/1] kvm: Output TSC offset 2013-06-12 7:43 [PATCH V3 0/1] kvm: Output TSC offset Yoshihiro YUNOMAE 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE 2013-06-12 7:46 ` [EXAMPLE] tools: a tool for merging trace data of a guest and a host Yoshihiro YUNOMAE @ 2013-06-23 7:58 ` Gleb Natapov 2013-06-25 10:16 ` [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 Yoshihiro YUNOMAE 2 siblings, 1 reply; 9+ messages in thread From: Gleb Natapov @ 2013-06-23 7:58 UTC (permalink / raw) To: Yoshihiro YUNOMAE Cc: Marcelo Tosatti, linux-kernel, David Sharp, yrl.pp-manager.tt, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, H. Peter Anvin, Masami Hiramatsu, Thomas Gleixner On Wed, Jun 12, 2013 at 04:43:41PM +0900, Yoshihiro YUNOMAE wrote: > Hi All, > Applied, thanks. > I'd like to propose a patch which adds a tracepoint at write_tsc_offset for > tracing guests TSC offset changes. It is required for sorting the trace data of > a guest and the host in chronological order. > > In a virtualization environment, it is difficult to analyze performance > problems, such as a delay of I/O request on a guest. This is because multiple > guests operate on the host. One of approaches for solving such kind of problems > is to sort trace data of guests and the host in chronological order. > > Raw TSC can be chosen as a timestamp of ftrace. I think TSC is useful for > merging trace data in chronological order by two reasons. One of the reasons is > that guests can directly read raw TSC from the CPU using rdtsc operation. This > means that raw TSC value is not software clock like sched_clock, so we don't > need to consider about how the timestamp is calculated. The other is that TSC > of recent x86 CPUs is constantly incremented. This means that we don't need to > worry about pace of the timestamp. Therefore, choosing TSC as a timestamp for > tracing is reasonable to integrate trace data of guests and a host. > > Here, we need to consider about just one matter for using TSC on guests. TSC > value on a guest is always the host TSC plus the guest's "TSC offset". In other > words, to merge trace data using TSC as timestamp in chronological order, we > need to consider TSC offset of the guest. > > However, only the host kernel can read the TSC offset from VMCS and TSC offset > is not output in anywhere now. In other words, tools in userland cannot get > the TSC offset value, so we cannot merge trace data of guest and the host in > chronological order. Therefore, I think the TSC offset should be exported for > userland tools. > > In this patch, TSC offset is exported by the tracepoint kvm_write_tsc_offset > on the host. TSC offset events will be very rare event because guests may > seldom execute write_tsc. So if we enable this event for a normal buffer of > ftrace, the events will be overwritten by other events. For a recent linux > kernel, a multiple buffer function is available. So, I recommend to enable > this event for a sub buffer of ftrace. > > <Example> > We assume that wakeup-latency for a command is big on a guest. Normally > we will use ftrace's wakeup-latency tracer or event tracer on the guest, but we > may not be able to solve this problem. This is because guests often exit to > the host for several reasons. In the next, we will use TSC as ftrace's timestamp > and record the trace data on the guest and the host. Then, we get following > data: > > /* guest data */ > comm-3826 [000] d...49836825726903: sched_wakeup: [detail] > comm-3826 [000] d...49836832225344: sched_switch: [detail] > /* host data */ > qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] > > Since TSC offset is not considered, these data cannot be merged. If this trace > data is shown like as follows, we will be able to understand the reason: > > qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > comm-3826 [000] d.h.49836825726903: sched_wakeup: [detail] <= > qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] > qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] > comm-3826 [000] d...49836832225344: sched_switch: [detail] <= > qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] > qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] > > In this case, we can understand wakeup-latency was big due to exit to host > twice. Getting this data sorted in chronological order is our goal. > > To merge the data like previous pattern, we apply this patch. Then, we can > get TSC offset of the guest as follows: > > # cat /sys/kernel/debug/tracing/instances/tsc_offset/trace > .. d...4300151845072: kvm_write_tsc_offset: vcpu=0 prev=0 next=18446739773557710924 > ^ ^^^^^^^^^^^^^^^^^^^^ > > We use this TSC offset value to a merge script and obtain the following data: > > $ ./trace-merge.pl -g guest_data -h host_data -t 18446739773557710924 > > h qemu-kvm-2687 [003] d...50550079203669: kvm_exit: [detail] > h qemu-kvm-2687 [003] d...50550079206816: kvm_entry: [detail] > g comm-3826 [000] d.h.50550079226331: sched_wakeup: [detail] <= > h qemu-kvm-2687 [003] d...50550079240656: kvm_exit: [detail] > h qemu-kvm-2687 [003] d...50550079243467: kvm_entry: [detail] > h qemu-kvm-2687 [003] d...50550079256103: kvm_exit: [detail] > h qemu-kvm-2687 [003] d...50550079268391: kvm_entry: [detail] > g comm-3826 [000] d...50550079279266: sched_switch: [detail] <= > h qemu-kvm-2687 [003] d...50550079280829: kvm_exit: [detail] > h qemu-kvm-2687 [003] d...50550079286028: kvm_entry: [detail] > | > \----guest/host > > In this summary, I suggest the patch which TSC offset for each guest can be > output on the host. > > As one example, I will send a merge tool. This tool assumes the guest doesn't > execute write_tsc. > > Changes in V2: > - Use tracepoint for outputting TSC offset value instead of printk() [1/1] > > Changes in V3: > - Add tracepoint in svm.c [1/1] > - Record vcpu_id [1/1] > - Change "previous=" to "prev=" in output result [1/1] > > Thanks! > > --- > > Yoshihiro YUNOMAE (1): > kvm: Add a tracepoint write_tsc_offset > > > arch/x86/kvm/svm.c | 10 +++++++++- > arch/x86/kvm/trace.h | 21 +++++++++++++++++++++ > arch/x86/kvm/vmx.c | 7 ++++++- > arch/x86/kvm/x86.c | 1 + > 4 files changed, 37 insertions(+), 2 deletions(-) > > -- > Yoshihiro YUNOMAE > Software Platform Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: yoshihiro.yunomae.ez@hitachi.com -- Gleb. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 2013-06-23 7:58 ` [PATCH V3 0/1] kvm: Output TSC offset Gleb Natapov @ 2013-06-25 10:16 ` Yoshihiro YUNOMAE 2013-06-25 10:18 ` Yoshihiro YUNOMAE 0 siblings, 1 reply; 9+ messages in thread From: Yoshihiro YUNOMAE @ 2013-06-25 10:16 UTC (permalink / raw) To: Gleb Natapov Cc: H. Peter Anvin, David Sharp, Marcelo Tosatti, linux-kernel, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, yrl.pp-manager.tt, Masami Hiramatsu, Paolo Bonzini, Thomas Gleixner, Joerg Roedel Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32. Since the tracepoint in trace.h was defined for CONFIG_X86_64, kernel build on i386 was failed. Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Gleb Natapov <gleb@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> --- arch/x86/kvm/trace.h | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index 6c82cf1..545245d 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -756,6 +756,27 @@ TRACE_EVENT( __entry->gpa_match ? "GPA" : "GVA") ); +TRACE_EVENT(kvm_write_tsc_offset, + TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, + __u64 next_tsc_offset), + TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), + + TP_STRUCT__entry( + __field( unsigned int, vcpu_id ) + __field( __u64, previous_tsc_offset ) + __field( __u64, next_tsc_offset ) + ), + + TP_fast_assign( + __entry->vcpu_id = vcpu_id; + __entry->previous_tsc_offset = previous_tsc_offset; + __entry->next_tsc_offset = next_tsc_offset; + ), + + TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, + __entry->previous_tsc_offset, __entry->next_tsc_offset) +); + #ifdef CONFIG_X86_64 #define host_clocks \ @@ -815,27 +836,6 @@ TRACE_EVENT(kvm_track_tsc, __print_symbolic(__entry->host_clock, host_clocks)) ); -TRACE_EVENT(kvm_write_tsc_offset, - TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, - __u64 next_tsc_offset), - TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), - - TP_STRUCT__entry( - __field( unsigned int, vcpu_id ) - __field( __u64, previous_tsc_offset ) - __field( __u64, next_tsc_offset ) - ), - - TP_fast_assign( - __entry->vcpu_id = vcpu_id; - __entry->previous_tsc_offset = previous_tsc_offset; - __entry->next_tsc_offset = next_tsc_offset; - ), - - TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, - __entry->previous_tsc_offset, __entry->next_tsc_offset) -); - #endif /* CONFIG_X86_64 */ #endif /* _TRACE_KVM_H */ ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 2013-06-25 10:16 ` [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 Yoshihiro YUNOMAE @ 2013-06-25 10:18 ` Yoshihiro YUNOMAE 2013-06-25 10:43 ` Gleb Natapov 0 siblings, 1 reply; 9+ messages in thread From: Yoshihiro YUNOMAE @ 2013-06-25 10:18 UTC (permalink / raw) To: Gleb Natapov Cc: H. Peter Anvin, David Sharp, Marcelo Tosatti, linux-kernel, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, yrl.pp-manager.tt, Masami Hiramatsu, Paolo Bonzini, Thomas Gleixner, Joerg Roedel Hi Gleb, Thank you for applying my patch. I received a mail of build error for i386, so I fixed the problem. Since the tracepoint was defined only for x86_64, build was failed in x86_32. Would you apply this patch to kvm-tree? Sorry for the inconvenience this may cause. Thank you, Yoshihiro YUNOMAE (2013/06/25 19:16), Yoshihiro YUNOMAE wrote: > Fix build error caused by an undefinition of the kvm_write_tsc_offset > tracepoint for x86_32. > Since the tracepoint in trace.h was defined for CONFIG_X86_64, kernel build > on i386 was failed. > > Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> > Cc: Joerg Roedel <joro@8bytes.org> > Cc: Gleb Natapov <gleb@redhat.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > --- > arch/x86/kvm/trace.h | 42 +++++++++++++++++++++--------------------- > 1 file changed, 21 insertions(+), 21 deletions(-) > > diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h > index 6c82cf1..545245d 100644 > --- a/arch/x86/kvm/trace.h > +++ b/arch/x86/kvm/trace.h > @@ -756,6 +756,27 @@ TRACE_EVENT( > __entry->gpa_match ? "GPA" : "GVA") > ); > > +TRACE_EVENT(kvm_write_tsc_offset, > + TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > + __u64 next_tsc_offset), > + TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > + > + TP_STRUCT__entry( > + __field( unsigned int, vcpu_id ) > + __field( __u64, previous_tsc_offset ) > + __field( __u64, next_tsc_offset ) > + ), > + > + TP_fast_assign( > + __entry->vcpu_id = vcpu_id; > + __entry->previous_tsc_offset = previous_tsc_offset; > + __entry->next_tsc_offset = next_tsc_offset; > + ), > + > + TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > + __entry->previous_tsc_offset, __entry->next_tsc_offset) > +); > + > #ifdef CONFIG_X86_64 > > #define host_clocks \ > @@ -815,27 +836,6 @@ TRACE_EVENT(kvm_track_tsc, > __print_symbolic(__entry->host_clock, host_clocks)) > ); > > -TRACE_EVENT(kvm_write_tsc_offset, > - TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > - __u64 next_tsc_offset), > - TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > - > - TP_STRUCT__entry( > - __field( unsigned int, vcpu_id ) > - __field( __u64, previous_tsc_offset ) > - __field( __u64, next_tsc_offset ) > - ), > - > - TP_fast_assign( > - __entry->vcpu_id = vcpu_id; > - __entry->previous_tsc_offset = previous_tsc_offset; > - __entry->next_tsc_offset = next_tsc_offset; > - ), > - > - TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > - __entry->previous_tsc_offset, __entry->next_tsc_offset) > -); > - > #endif /* CONFIG_X86_64 */ > > #endif /* _TRACE_KVM_H */ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae.ez@hitachi.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 2013-06-25 10:18 ` Yoshihiro YUNOMAE @ 2013-06-25 10:43 ` Gleb Natapov 0 siblings, 0 replies; 9+ messages in thread From: Gleb Natapov @ 2013-06-25 10:43 UTC (permalink / raw) To: Yoshihiro YUNOMAE Cc: H. Peter Anvin, David Sharp, Marcelo Tosatti, linux-kernel, Steven Rostedt, Hidehiro Kawai, Ingo Molnar, yrl.pp-manager.tt, Masami Hiramatsu, Paolo Bonzini, Thomas Gleixner, Joerg Roedel On Tue, Jun 25, 2013 at 07:18:35PM +0900, Yoshihiro YUNOMAE wrote: > Hi Gleb, > > Thank you for applying my patch. > I received a mail of build error for i386, so I fixed the problem. > Since the tracepoint was defined only for x86_64, build was failed in > x86_32. > > Would you apply this patch to kvm-tree? > Sorry for the inconvenience this may cause. > No inconvenience. I amended your previous commit since it was still on the branch that can be rebased. > Thank you, > Yoshihiro YUNOMAE > > (2013/06/25 19:16), Yoshihiro YUNOMAE wrote: > >Fix build error caused by an undefinition of the kvm_write_tsc_offset > >tracepoint for x86_32. > >Since the tracepoint in trace.h was defined for CONFIG_X86_64, kernel build > >on i386 was failed. > > > >Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> > >Cc: Joerg Roedel <joro@8bytes.org> > >Cc: Gleb Natapov <gleb@redhat.com> > >Cc: Paolo Bonzini <pbonzini@redhat.com> > >Cc: Thomas Gleixner <tglx@linutronix.de> > >Cc: Ingo Molnar <mingo@redhat.com> > >Cc: "H. Peter Anvin" <hpa@zytor.com> > >--- > > arch/x86/kvm/trace.h | 42 +++++++++++++++++++++--------------------- > > 1 file changed, 21 insertions(+), 21 deletions(-) > > > >diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h > >index 6c82cf1..545245d 100644 > >--- a/arch/x86/kvm/trace.h > >+++ b/arch/x86/kvm/trace.h > >@@ -756,6 +756,27 @@ TRACE_EVENT( > > __entry->gpa_match ? "GPA" : "GVA") > > ); > > > >+TRACE_EVENT(kvm_write_tsc_offset, > >+ TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > >+ __u64 next_tsc_offset), > >+ TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > >+ > >+ TP_STRUCT__entry( > >+ __field( unsigned int, vcpu_id ) > >+ __field( __u64, previous_tsc_offset ) > >+ __field( __u64, next_tsc_offset ) > >+ ), > >+ > >+ TP_fast_assign( > >+ __entry->vcpu_id = vcpu_id; > >+ __entry->previous_tsc_offset = previous_tsc_offset; > >+ __entry->next_tsc_offset = next_tsc_offset; > >+ ), > >+ > >+ TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > >+ __entry->previous_tsc_offset, __entry->next_tsc_offset) > >+); > >+ > > #ifdef CONFIG_X86_64 > > > > #define host_clocks \ > >@@ -815,27 +836,6 @@ TRACE_EVENT(kvm_track_tsc, > > __print_symbolic(__entry->host_clock, host_clocks)) > > ); > > > >-TRACE_EVENT(kvm_write_tsc_offset, > >- TP_PROTO(unsigned int vcpu_id, __u64 previous_tsc_offset, > >- __u64 next_tsc_offset), > >- TP_ARGS(vcpu_id, previous_tsc_offset, next_tsc_offset), > >- > >- TP_STRUCT__entry( > >- __field( unsigned int, vcpu_id ) > >- __field( __u64, previous_tsc_offset ) > >- __field( __u64, next_tsc_offset ) > >- ), > >- > >- TP_fast_assign( > >- __entry->vcpu_id = vcpu_id; > >- __entry->previous_tsc_offset = previous_tsc_offset; > >- __entry->next_tsc_offset = next_tsc_offset; > >- ), > >- > >- TP_printk("vcpu=%u prev=%llu next=%llu", __entry->vcpu_id, > >- __entry->previous_tsc_offset, __entry->next_tsc_offset) > >-); > >- > > #endif /* CONFIG_X86_64 */ > > > > #endif /* _TRACE_KVM_H */ > > > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >the body of a message to majordomo@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > >Please read the FAQ at http://www.tux.org/lkml/ > > > > -- > Yoshihiro YUNOMAE > Software Platform Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: yoshihiro.yunomae.ez@hitachi.com > -- Gleb. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-06-25 10:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-12 7:43 [PATCH V3 0/1] kvm: Output TSC offset Yoshihiro YUNOMAE 2013-06-12 7:43 ` [PATCH V3 1/1] kvm: Add a tracepoint write_tsc_offset Yoshihiro YUNOMAE 2013-06-12 22:44 ` Marcelo Tosatti 2013-06-24 15:02 ` Paolo Bonzini 2013-06-12 7:46 ` [EXAMPLE] tools: a tool for merging trace data of a guest and a host Yoshihiro YUNOMAE 2013-06-23 7:58 ` [PATCH V3 0/1] kvm: Output TSC offset Gleb Natapov 2013-06-25 10:16 ` [PATCH] [BUGFIX] Fix build error caused by an undefinition of the kvm_write_tsc_offset tracepoint for x86_32 Yoshihiro YUNOMAE 2013-06-25 10:18 ` Yoshihiro YUNOMAE 2013-06-25 10:43 ` Gleb Natapov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).