Re: [Xen-devel] [PATCH][xentrace][HVM] introduce HVM tracing to unify SVM and VMX tracing

["George Dunlap" <gdunlap@xxxxxxxxxxxxx>]

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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel