[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] [HVM] fix tracing for 64bit guests

Hi Keir,

I saw you were committing some changes to my patch:

-    if ( hvm_long_mode_enabled(v) )
-        HVMTRACE_ND (VMEXIT64, 1/*cycles*/, v, 3, exit_reason,
-            regs->eip & 0xFFFFFFFF, regs->eip >> 32, 0, 0, 0);
-    else
-        HVMTRACE_ND (VMEXIT, 1/*cycles*/, v, 2, exit_reason,
-            regs->eip, 0, 0, 0, 0);
+    HVMTRACE_ND(VMEXIT64, 1/*cycles*/, v, 3, exit_reason,
+                (uint32_t)regs->eip, (uint32_t)((uint64_t)regs->eip >> 32),
+                0, 0, 0);

This basically will always log 64bit values for the instruction pointer. I thought about this approach, too, but didn't do it because I got the impression that trace files are large enough and with the recently introduced 'variable number of parameters' saving disk space is a concern. Do you want to promote other pointers to always 64bit, too? Shall I prepare a patch for this? I also had the idea to include gzipping in the xentrace tool, this should save about 80% of disk space at the cost of a slightly higher Dom0 load (or use lzo?). Is this something I should implement?


Andre Przywara wrote:

Xen tracing some times ago used to put values of type 'long' into the trace buffer. This has changed to uint32_t. Some trace points log virtual addresses, which get cropped to 32bit in this case. There were some inline functions to handle at least PF_XEN and VMEXIT, which caused a lot of code duplication. The attached patch fixes several issues:
1. fix and extend tools/xentrace/formats
2. Fix xentrace_format to handle up to 7 parameters
3. create convenience macros to properly log long values
4. remove the inline functions in hvm/trace.h and replace them by macros
5. Change the CPUID trace to work correctly
6. group HVM trace points enable mechanism

I used a similar approach as in PV tracing with bit 8 indicating 64bit pointers.

Discussion welcome!

Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>

BTW: Why is xentrace_format so awfully slow? I have rewritten the tool in C and reached a speedup of more than 20 times. If someone bugs me I will share the code...


Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.