Re: wrong vmexit size in xenalyze

[George Dunlap <George.Dunlap@eu.citrix.com>]

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"<olaf@aepfle.de>  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<keir.fraser@citrix.com>
>>   # 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
>
>