Re: [Xen-devel] wrong vmexit size in xenalyze

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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@xxxxxxxxx>  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@xxxxxxxxxx>
> >   # 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel