> 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
|
Home