WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][xentrace][HVM] introduce HVM tracing to unify SV

To: "George Dunlap" <gdunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][xentrace][HVM] introduce HVM tracing to unify SVM and VMX tracing
From: "Thomas Friebel" <thomas.friebel@xxxxxxx>
Date: Tue, 27 Feb 2007 13:28:46 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Feb 2007 04:27:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0702261154x26fba675s4207faaf587105a6@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1172501111.4381.30.camel@xxxxxxxxxxxxxxxxxxxxxxx> <de76405a0702261154x26fba675s4207faaf587105a6@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> First, there's a lot of manual duplication here.  This is just begging
> for the VMX and SVM code to get out of sync again.  Would it be easier
> if we made a series of macros that each called; e.g.,
> 
> #define HVMTRACE_PF_XEN(v, _eq, _ec) \
>     HVMTRACE_2D(v, _eq, _ec)
> 
> Then, in the appropriate place in each file:
>   HVMTRACE_PF_XEN(v, exit_qualification, regs->error_code);
> 
> This way, if someone modifies the trace, they'll be prompted by the
> compiler to modify it in both places.

Yes, this way you can't easily add or remove parameters on one side
(SVM/VMX) and ignore the other (VMX/SVM). But I think the improvement is
not that big.

We could introduce one inline function per trace event. This way we'd
additionally assure type correctness of the parameters.


> Second, about taking traces as you go along rather than storing up
> data to be traced at the next vmenter.  I'm curious what your
> reasoning was behind this?

The main reason was to be able to exploit the xentrace_format feature.
For a nice formatting of the trace logs we need one event ID per format
string. In the format file we dedicate one line per event ID and this
way have readable and much easier understandable output.

This sums up to at least three trace entries per round trip instead of
two:
* one entry on #VMEXIT just for the exit reason and the timestamp
* one or more entries giving information about the execution path
* one entry just before VMENTRY giving a final timestamp.

If we really want to optimize for trace file size we could remember the
exit reason and timestamp on #VMEXIT and stick with saving the trace
data until just before VMENTRY. Then all the data is packed into one
trace entry with the specific event ID for formatting.

But by doing that there is no clean way of logging the execution path.
So I decided to have the 3+ trace entries per roundtrip and to include a
facility to toggle single events on and off. The easiest way was to
introduce some #defines to do this at compile time.

Cheers,
  Thomas




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