From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: wrong vmexit size in xenalyze Date: Fri, 19 Nov 2010 09:50:03 +0000 Message-ID: <4CE6484B.9000707@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Olaf Hering , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Yeah, doing some archeology... looks like the trace size for the HVMTRACE_ND macro is has an off-by-one error since domain_id and vcpu_id were removed from HVM trace records in September 2008. Tracing is definitely not a stable ABI between releases, but it should be reasonably stable after a release. Originally I tried having xenalyze detect and deal with different trace layouts, but it made the code just too much of a mess. I could have simply tagged xenalyze on a release, but then future improvements to xenalyze wouldn't be able to be used on released versions of Xen. My most recent attempt is to have xenalyze always be compatible with -unstable, but to have back-patches (found in xenalyze.hg/back-patches/) to change the file format to earlier versions. But obviously that requires some more vigilance to making and testing back-patches for previous versions. If you have a better idea, I'm open to it. A bit more discipline -- doing an audit of the tracing after the feature freeze before each release -- would be helpful; some automated testing would be even more helpful. -George On 19/11/10 09:34, Keir Fraser wrote: > Xenalyze should do a Xen version check and do the appropriate thing for 4.0 > and earlier versus 4.1 and later. Changing visible behaviour of a Xen stable > branch will just add to the confusion. > > -- Keir > > On 19/11/2010 09:23, "Olaf Hering" wrote: > >> George, >> >> what is the reason behind this changeset? >> http://xenbits.xensource.com/ext/xenalyze.hg?rev/9fa7e4d2a3af >> >> All my vmexit trace entries have size 4 for 64bit and 3 for 32bit. >> Looking at the code in ./xen/arch/x86/hvm/vmx/vmx.c, HVMTRACE_ND() gets >> size 3 for VMEXIT64. But HVMTRACE_ND does a 'sizeof(u32)*count+1' in >> xen-4.0. >> The xen-unstable macro looks different. It was changed in this revision: >> >> # 8 weeks ago: x86/hvm: fix extra size passed to __trace_var() >> # revision 10: 9cebb977e9d8 (diff) (annotate) >> # author: Keir Fraser >> # date: Mon Sep 20 18:53:18 2010 +0100 >> >> I think this means most of the extra_words checks are bogus now, unless >> the same change also goes into the 4.0 branch. >> >> What should we do about this difference in tracedata? >> >> >> Olaf >> >> --- a/xenalyze.c Wed Nov 10 14:56:56 2010 +0000 >> +++ b/xenalyze.c Wed Nov 10 14:58:31 2010 +0000 >> @@ -4828,8 +4828,8 @@ void hvm_vmexit_process(struct record_in >> }; >> } *r; >> >> - if(ri->extra_words != 4 >> -&& ri->extra_words != 3 >> + if(ri->extra_words != 3 >> +&& ri->extra_words != 2 >> ) >> { >> fprintf(warn, "FATAL: vmexit has unexpected extra words %d!\n", >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > >