[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.