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

[Andre Przywara <andre.przywara@xxxxxxx>]

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?
Regards,
Andre

Andre Przywara wrote:
> Hi,
>
> 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...
> Regards,
> Andre.
--
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel