Re: [Xen-devel] Xentrace on Xilinx ARM

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 08/03/16 20:51, Ben Sanda wrote:
> George,
> 
>> FWIW, on my "to-do" list for xenalyze for years has been to have the xentrace
>> process query something (either Xen or Linux) to find the hz rate, and then
>> write that at the beginning of the xentrace file, so that xenalyze could just
>> pick that up and use it.  Since you're doing some work on xentrace / xenalyze
>> anyway, you might think about adding that to your "to-do" list -- it doesn't
>> seem conceptually like it would be that hard.
> 
> Since I'm in the code base anyway right now I'll give it a look. I was 
> wondering
> about that for the xenalyze hertz parameter. I had assumed initially xentrace
> embedded the value somehow already. Is there any documentation as to the 
> binary
> format xentrace outputs? Or is it best just to look at the code and figure it
> out? I guess the main thing would be providing a common interface for both ARM
> and x86 but the common trace.c has a get frequency function that's implemented
> by both so we should be able to query it and shove in the data.

Well fundamentally the output is a series of variable-sized records of
"struct t_rec", defined in xen/include/public/trace.h.  Each trace is at
least one word (4 bytes) long, and at most 10 words (40 bytes) long.  I
think between the t_rec definition and the code that handles it in
xenalyze you should be able to figure out what's going on. :-)

Xen creates one ring-buffer per cpu and simply writes trace records into
the buffers (with producer / consumer pointers).  If the buffer is full,
it simply drops trace records; however, it counts  how many records get
dropped, and when there is space again it creates a TRC_LOST_RECORDS
trace record that contains:
1. The number of lost records
2. The tsc of the first lost record (which, with the current tsc, gives
you a clear picture of the timeframe over which records were lost)
3. The currently running vcpu (so you can tell which vcpu to account the
records until the next schedule trace record)

xentrace will intermittently wake up and check for outstanding records
in the cpu buffers.  For each buffer it finds consumed records, it
creates a TRC_CPU_CHANGE record, which says the physical cpu of the
following records, as well as the number of bytes about to be written.
This allows xenalyze to efficiently scan through the file looking for
records from a specific pcpu.

So xentrace already generates new trace records and inserts them into
the stream.  The new functionality we're talking about would just be a
matter of defining a new trace record or two (probably of time TRC_GEN
-- see TRC_CPU_CHANGE in xen/include/public/trace.h), then getting
xentrace to add the records at the beginning of the trace file.

I *think* that you could get away with not writing a TRC_CPU_CHANGE
record for those trace records; but it wouldn't really hurt to insert
one anyway.  I'll leave that up to you.

>> The other thing that might be useful is information about the architecture
>> you're running on -- right now it assumes intel, and will crash tracing a 
>> file
>> generated on an AMD box unless you specify --svm-mode.  Adding a trace record
>> that indicates "Intel / AMD / ARM" would also make things a lot easier.
> 
> I didn't run into any issue with xenalyze analyzing the ARM generated trace 
> file
> (I didn't give it any special flag). What does --svm-mode modify? The 
> endedness?
> I can look quick into that as well.

"SVM" is* AMD's name for their virtualization extension (as "VMX" or
"VT-x" is for Intel).

* Or at least, it was at one time -- they tend to rename these things
for marketing reasons.

If you're just doing a straight dump of the records, with no analysis,
then it's probably not a big deal.  The main thing with Intel / AMD is
that they have different VMEXIT types, so xenalyze needs to know which
one it's getting to be able to analyze them properly.

On the other hand, maybe what we should do is just have a flag in the
architecture-specific trace records themselves saying whether they
should be interpreted as VMX or SVM. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel