Xen devel - Feb 2007 - [PATCH][xentrace][HVM] introduce HVM tracing to unify SVM and VMX tracing

Hello,

this patch introduces HVM tracing: one tracing class for both, SVM and
VMX.

It adds several new trace events. So we can differentiate between them
in the xentrace formats file and format each event''s data items
appropriately. With this patch the xentrace_format output is much more
informative.

The previous simple tracing in SVM and VMX is completely replaced.
Unfortunately I could not yet test the VMX part beyond compiling. Any
volunteers? Help is very much appreciated!

Some short notes just to mention: This patch does not break xenmon. I
don''t know any other users of xentrace. The manpage for xentrace is
updated. The xentrace command line parameter -e now accepts "hvm". 

Cheers
  Thomas



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

+1 to the idea, seems like a good way to do things.

Premusably the resulting functionality is a superset of the previous tracing 
capabilities?

I have no objections to the Xentrace-related changes, all looks sensible and 
useful.  Did spot anything in particular to complain about in the HVM code 
either, but I didn''t look that hard at those parts.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

I''m glad someone from AMD is interested in this -- I''ve been
using the
VMX tracing extensively, and have long thought unifying them would be
a good idea.  Thanks for taking the initiative on this.

A couple of comments:

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.


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?

Your method has the advantage that the "info" trace itself has more
data; rather than taking up 2 slots with vmentry and the "exit reason"
(for VMX), you have more space available for other information.

There are some disadvantages though.  First, it automatically
increases the size of the trace by 50%.  Many of my traces reach in
the multi-gigabyte range, so this is a concern for me.  We''ve
discussed variable-size trace buffers on the list before, but I don''t
remember if anyone volunteered to actually do it.

One of the advantages of tracing it at the end is the ability to set
little bits as you go.  I have some private ''extensions'' to
the VMX
tracing that gives a lot more information about, for example, the page
fault path.  One of the things that I do is have a set of flags that
get set depending on different paths that get taken -- for example,
was a page promoted?  Did any accessed or dirty bits get set? And so
on.  With the current setup, I can just have the code flip the bit in
hvm_trace_values[] directly.  Under a setup like yours, I''d have to do
that manually for each one.

Overall, I think the +50% trace size is a big minus for me.

I''ll look over the actual changes to VMX a little more closely, and
give it a test run tomorrow.

Peace,
 -George

On 2/26/07, Thomas Friebel <thomas.friebel@amd.com>
wrote:
> Hello,
>
> this patch introduces HVM tracing: one tracing class for both, SVM and
> VMX.
>
> It adds several new trace events. So we can differentiate between them
> in the xentrace formats file and format each event''s data items
> appropriately. With this patch the xentrace_format output is much more
> informative.
>
> The previous simple tracing in SVM and VMX is completely replaced.
> Unfortunately I could not yet test the VMX part beyond compiling. Any
> volunteers? Help is very much appreciated!
>
> Some short notes just to mention: This patch does not break xenmon. I
> don''t know any other users of xentrace. The manpage for xentrace
is
> updated. The xentrace command line parameter -e now accepts
"hvm".
>
> Cheers
>   Thomas
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

On Monday, 26.02.2007, 18:33 +0000 Mark Williamson
wrote:
> Premusably the resulting functionality is a superset of the previous
tracing
> capabilities?
Yes this is what I intended. I hope I didn''t miss a point.

Cheers,
  Thomas


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