Xen devel - Jun 2008 - [PATCH] [HVM] fix tracing for 64bit guests

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@amd.com>

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@amd.com>
> 
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/6/08 09:53, "Andre Przywara" <andre.przywara@amd.com>
wrote:
> 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?
My opinion is if it''s efficient enough for 64-bit guests then it must
be
good enough for 32-bit guests too. Further, I don''t want extra usually
unnecessary checks on the common vmentry/vmexit paths, and always using the
64-bit version reduces code clutter.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel