From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset Date: Fri, 16 Nov 2012 08:05:48 -0200 Message-ID: <20121116100548.GA20892@amt.cnet> References: <20121114013611.5338.15086.stgit@yunodevel> <20121116031946.GA23939@amt.cnet> <50A5F4C4.2030909@hitachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, Joerg Roedel , David Sharp , Steven Rostedt , Hidehiro Kawai , Ingo Molnar , Avi Kivity , yrl.pp-manager.tt@hitachi.com, Masami Hiramatsu , Thomas Gleixner To: Yoshihiro YUNOMAE Return-path: Content-Disposition: inline In-Reply-To: <50A5F4C4.2030909@hitachi.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, Nov 16, 2012 at 05:09:40PM +0900, Yoshihiro YUNOMAE wrote: > Hi Marcelo, > > Thank you for commenting on my patch set. > > (2012/11/16 12:19), Marcelo Tosatti wrote: > >On Wed, Nov 14, 2012 at 10:36:21AM +0900, Yoshihiro YUNOMAE wrote: > [...] > >>In this summary, I suggest the patch which TSC offset for each guest can be > >>output on the host. > > > >The guest TSC can change (for example if TSC scaling is used). Moreover > >TSC offset can change, and you'd have to monitor that. What > > Yes, that's true. Changing TSC offset is the key point to use TSC for > merging trace data of guests and the host. > > >about a module option so that tsc_offset is written as zero (to be > >used as debugging tool). Then the following restrictions apply: > > > >- TSC must be synchronized across CPUs/VCPUS. > >- TSC must be reliable. > > > >Would that suffice? (a module option to kvm.ko, say zero_tsc_offset). > > As you say, the guest TSC can change, so guest TSC needs to meet these > two restrictions to merge the trace data in chronological order. > > However, the zero-TSC offset method is not enough, I think. > I will use TSC values as the tracing timestamp not only for debugging > but for failure analysis on actual operations. When we introduce > the zero-TSC offset, normally it will be no problem. However, if > the guest executes write_tsc or the guest works live migration, TSC > offset will be changed. After all, we need to monitor the TSC offset > value. > > Thank you, What i wrote was not precise. With TSC scaling (of AMD's svm.c) or TSC trapping, the guest RDTSC is not monotonic with reference to the host TSC. That is, TSC scaling and/or trapping are fundamentally incompatible with the feature you propose. What you are saying is that is you'd like this feature for production, not debugging. Unfortunately this requires a synchronized TSC across CPUs, which is not widespread. Therefore the suggestion to introduce a debugging facility (you cannot rely on this for failure analysis on all systems). Even then, a more reliable method for reporting TSC offset must be used. Apart from these issues, it is very useful to correlate guest/host events in the way you propose.