[HVM][XENOPROFILE][RFC][0/3] xenoprofile HVM patches

[HVM][XENOPROFILE][RFC][0/3] xenoprofile HVM patches

[Woller, Thomas]

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]

Keir, 
The following 3 patches allow HVM (SVM and VT) guests to be passively
profiled using the very latest patches from Renato.  These patches apply
to 11470.
Renato's patches:
http://xenoprof/sourceforge.net  oprofile-0.9.1-xen-r2.patch
And also a patch not posted FAIK
(oprofile-0.9.1-fix-hvm-addr-overlap.patch) which is in the attached
tar.bz2 file.

hvm_xenoprofile_1.patch -
The first patch is merely the same patch that I posted a few weeks ago.
The STGI code is moved from the exits.S files, and into the vmexit
handler.  The extra do_nmi() is removed allowing the host to handle the
NMI when the stgi instruction is executed.  This patch allows the second
patch to properly set "guest NMI" flag for the oprofile code to
determine proper rip/eip and mode.

hvm_xenoprofile_2.patch -
The second patch adds the actual xenoprofile fixes for SVM:

1) hvm function (svm_oprofile_get_eip())
This new hvm table function is called from the op_module_athlon.c code,
and returns the proper eip and "mode" for use in the
xenoprof_log_event() function.  

2) The vmexit handler code now checks the exitcode and if an NMI was
intercepted, then prior to the stgi(), a flag (VGCF_hvm_guest_nmi) is
set in the v->arch.guest_context.flags field.   The VGCF_hvm_guest_nmi
bit is checked during NMI processing via the hvm function callback. 

hvm_xenoprofile_3.patch -
The third patch adds the actual xenoprofile fixes for VT:
I checked (verified by Renato), that the VT traces look ok also.  There
is some code that I am unsure about in the vmx_oprofile_get_eip(): i.e
using the __vmread() to get eip might not be in the proper context, and
then secondly I am not sure how to determine the guest CPL level.

Overall, these patches seem to work fine for 32bit hypervisor, as well
as 64bit hypervisor with 32bit and 64bit HVM guests.  You do need to use
both of Renato's oprofile patches on top of 0.9.1.  With another
oprofile release soon (this week?), I believe that some of the "r2"
patch will be incorporated into 0.9.2, but not sure which parts.

There certainly might be a better way to obtain the eip/mode, but since
the SVM code is not calling do_nmi() then the host context will handle
the NMI, and there must be some mechanism to properly setup the eip/mode
in the op_model code indirectly.  I am not sure if the VT code requires
the same approach since do_nmi() is called directly, and the eip/mode
could be passed directly to this function.

The attached tar.bz2 file contains some example logs, and some scripts
from Ray Bryant (AMD) for extracting and normalizing each of the
profiling buckets.  There is a brief README for using the scripts. 

We'd like to see this get into 3.0.3 if possible.  Renato has reviewed
the patches, but not actually tested these patches on his platforms.
Feedback appreciated,
Tom Woller



[-- Attachment #2: xenoprofile_hvm.tar.bz2 --]
[-- Type: application/octet-stream, Size: 12840 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

[XENOPROLIFE] New oprofile patch for XenOProfile

[Santos, Jose Renato G]

[-- Attachment #1: Type: text/plain, Size: 4186 bytes --]

Tom,

Thanks for the HVM patches.
This is good news

We are now able to profile HVM guests (both SVM and VT)(in passive mode)
using Tom's patches combined with the attached new version of oprofile.
The attached patch (r3) combines the old oprofile patch (r2) with the
patch "oprofile-0.9.1-fix-hvm-addr-overlap.patch" that Tom mentioned and
included in his post.
After Tom's fixes are merged, this is the only patch that will be
needed.

The patch is for oprofile 0.9.1. Oprofile 0.9.2, which will be release
soon, will include XenOprofile support for active domains but it will
not support passive domains. I will generate a patch with passive domain
support for oprofile 0.9.2 when it is released.

I hope Tom patches are accepted and make into Xen 3.0.3

Thanks

Renato

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Woller, Thomas
> Sent: Friday, September 15, 2006 9:19 AM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [HVM][XENOPROFILE][RFC][0/3] xenoprofile 
> HVM patches
> 
> Keir,
> The following 3 patches allow HVM (SVM and VT) guests to be 
> passively profiled using the very latest patches from Renato. 
>  These patches apply to 11470.
> Renato's patches:
> http://xenoprof/sourceforge.net  oprofile-0.9.1-xen-r2.patch 
> And also a patch not posted FAIK
> (oprofile-0.9.1-fix-hvm-addr-overlap.patch) which is in the attached
> tar.bz2 file.
> 
> hvm_xenoprofile_1.patch -
> The first patch is merely the same patch that I posted a few 
> weeks ago.
> The STGI code is moved from the exits.S files, and into the 
> vmexit handler.  The extra do_nmi() is removed allowing the 
> host to handle the NMI when the stgi instruction is executed. 
>  This patch allows the second patch to properly set "guest 
> NMI" flag for the oprofile code to determine proper rip/eip and mode.
> 
> hvm_xenoprofile_2.patch -
> The second patch adds the actual xenoprofile fixes for SVM:
> 
> 1) hvm function (svm_oprofile_get_eip()) This new hvm table 
> function is called from the op_module_athlon.c code, and 
> returns the proper eip and "mode" for use in the
> xenoprof_log_event() function.  
> 
> 2) The vmexit handler code now checks the exitcode and if an 
> NMI was intercepted, then prior to the stgi(), a flag 
> (VGCF_hvm_guest_nmi) is
> set in the v->arch.guest_context.flags field.   The VGCF_hvm_guest_nmi
> bit is checked during NMI processing via the hvm function callback. 
> 
> hvm_xenoprofile_3.patch -
> The third patch adds the actual xenoprofile fixes for VT:
> I checked (verified by Renato), that the VT traces look ok 
> also.  There is some code that I am unsure about in the 
> vmx_oprofile_get_eip(): i.e using the __vmread() to get eip 
> might not be in the proper context, and then secondly I am 
> not sure how to determine the guest CPL level.
> 
> Overall, these patches seem to work fine for 32bit 
> hypervisor, as well as 64bit hypervisor with 32bit and 64bit 
> HVM guests.  You do need to use both of Renato's oprofile 
> patches on top of 0.9.1.  With another oprofile release soon 
> (this week?), I believe that some of the "r2"
> patch will be incorporated into 0.9.2, but not sure which parts.
> 
> There certainly might be a better way to obtain the eip/mode, 
> but since the SVM code is not calling do_nmi() then the host 
> context will handle the NMI, and there must be some mechanism 
> to properly setup the eip/mode in the op_model code 
> indirectly.  I am not sure if the VT code requires the same 
> approach since do_nmi() is called directly, and the eip/mode 
> could be passed directly to this function.
> 
> The attached tar.bz2 file contains some example logs, and 
> some scripts from Ray Bryant (AMD) for extracting and 
> normalizing each of the profiling buckets.  There is a brief 
> README for using the scripts. 
> 
> We'd like to see this get into 3.0.3 if possible.  Renato has 
> reviewed the patches, but not actually tested these patches 
> on his platforms.
> Feedback appreciated,
> Tom Woller
> 
> 
> 

[-- Attachment #2: oprofile-0.9.1-xen-r3.patch --]
[-- Type: application/octet-stream, Size: 28204 bytes --]

Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>

diff -aur oprofile-0.9.1/ChangeLog oprofile-0.9.1-xen-r3/ChangeLog
--- oprofile-0.9.1/ChangeLog	2005-07-18 13:02:37.000000000 -0700
+++ oprofile-0.9.1-xen-r3/ChangeLog	2006-09-15 11:45:26.000000000 -0700
@@ -1,3 +1,38 @@
+2006-09-15  Jose Renato Santos  <jsantos@hpl.hp.com>
+
+	* daemon/opd_kernel.c: Use cpu mode to distinguish
+	  samples from user/kernel/xen instead of using
+	  the address range. In Xen, fully virtualized guests
+	  can have kernel addresses that overlap Xen
+	  addresses
+
+2006-08-23  Jose Renato Santos  <jsantos@hpl.hp.com>
+
+	* daemon/init.c:
+	* daemon/opd_interface.h:
+	* daemon/opd_kernel.h:
+	* daemon/opd_kernel.c:
+	* daemon/opd_sfile.c:
+	* daemon/opd_trans.h:
+	* daemon/opd_trans.c:
+	* daemon/oprofiled.h:
+	* daemon/oprofiled.c:
+	* doc/opcontrol.1.in:
+	* utils/opcontrol: Added support for passive 
+	  domains in Xen (for Xen 3.0.3)
+
+2005-12-22  Jose Renato Santos  <jsantos@hpl.hp.com>
+
+	* daemon/init.c:
+	* daemon/opd_interface.h:
+	* daemon/opd_kernel.h:
+	* daemon/opd_kernel.c:
+	* daemon/opd_trans.c:
+	* daemon/oprofiled.h:
+	* daemon/oprofiled.c:
+	* doc/opcontrol.1.in:
+	* utils/opcontrol: Added support for Xen
+
 2005-07-18  John Levon  <levon@movementarian.org>
 
 	* libutil++/tests/Makefile.am: canonicalize
diff -aur oprofile-0.9.1/daemon/init.c oprofile-0.9.1-xen-r3/daemon/init.c
--- oprofile-0.9.1/daemon/init.c	2005-05-02 08:06:57.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/init.c	2006-09-01 09:38:15.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #include "config.h"
@@ -222,6 +225,9 @@
 	size_t opd_buf_size;
 
 	opd_create_vmlinux(vmlinux, kernel_range);
+	opd_create_xen(xenimage, xen_range);
+	if (xen_passive_setup)
+		opd_create_passive(xen_passive_setup);
 
 	opd_buf_size = opd_read_fs_int("/dev/oprofile/", "buffer_size", 1);
 	kernel_pointer_size = opd_read_fs_int("/dev/oprofile/", "pointer_size", 1);
diff -aur oprofile-0.9.1/daemon/opd_interface.h oprofile-0.9.1-xen-r3/daemon/opd_interface.h
--- oprofile-0.9.1/daemon/opd_interface.h	2005-04-13 19:14:17.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/opd_interface.h	2006-09-01 09:38:15.000000000 -0700
@@ -8,6 +8,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #ifndef OPD_INTERFACE_H
@@ -17,10 +20,14 @@
 #define CPU_SWITCH_CODE			2
 #define COOKIE_SWITCH_CODE		3
 #define KERNEL_ENTER_SWITCH_CODE	4
-#define KERNEL_EXIT_SWITCH_CODE		5
-#define MODULE_LOADED_CODE              6
+#define USER_ENTER_SWITCH_CODE		5
+#define MODULE_LOADED_CODE		6
 #define CTX_TGID_CODE			7
 #define TRACE_BEGIN_CODE		8
-#define LAST_CODE			9
+/* Code 9 used to be TRACE_END_CODE which is not used anymore  */
+/* Code 9 is now considered an unknown escape code             */
+#define XEN_ENTER_SWITCH_CODE		10
+#define DOMAIN_SWITCH_CODE		11
+#define LAST_CODE			12
  
 #endif /* OPD_INTERFACE_H */
diff -aur oprofile-0.9.1/daemon/opd_kernel.c oprofile-0.9.1-xen-r3/daemon/opd_kernel.c
--- oprofile-0.9.1/daemon/opd_kernel.c	2004-01-29 12:00:26.000000000 -0800
+++ oprofile-0.9.1-xen-r3/daemon/opd_kernel.c	2006-09-15 11:54:42.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #include "opd_kernel.h"
@@ -29,6 +32,13 @@
 
 static struct kernel_image vmlinux_image;
 
+static struct kernel_image xen_image;
+
+static LIST_HEAD(passive_vmlinux);
+static LIST_HEAD(passive_xen);
+static LIST_HEAD(passive_apps);
+static LIST_HEAD(passive_modules);
+
 void opd_create_vmlinux(char const * name, char const * arg)
 {
 	/* vmlinux is *not* on the list of modules */
@@ -54,6 +64,107 @@
 	}
 }
 
+void opd_create_xen(char const * name, char const * arg)
+{
+	int stat;
+
+	/* xen is *not* on the list of modules */
+	list_init(&xen_image.list);
+
+	/* for no xen */
+	if (no_xen) {
+		xen_image.name = "no-xen";
+		return;
+	}
+
+	xen_image.name = xstrdup(name);
+
+	stat = sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
+
+	verbprintf(vmisc, "xen_start = %llx, xen_end = %llx\n",
+	           xen_image.start, xen_image.end);
+
+	if ( stat != 2 ) {
+		fprintf(stderr, "error: mis-parsed xen range: %llx-%llx\n",
+		        xen_image.start, xen_image.end);
+		exit(EXIT_FAILURE);
+	}
+}
+
+void opd_create_passive_domain(int id, char const * image_kernel, 
+			       char const * range, char const * image_xen)
+{
+	char file[64];
+	struct kernel_image * image;
+	int stat;
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_kernel);
+	image->start = image->end = 0; 
+	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
+	image->id = id;
+	list_add(&image->list, &passive_vmlinux);
+	
+	if ( stat != 2 ) {
+		fprintf(stderr, "error: mis-parsed passive domain range for "
+			"domain %d: %llx-%llx\n", id, image->start, image->end);
+		exit(EXIT_FAILURE);
+	}
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_xen);
+	image->start = xen_image.start;
+	image->end = xen_image.end;
+	image->id = id;
+	list_add(&image->list, &passive_xen);
+
+	sprintf(file, "domain%d-apps", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	image->id = id;
+	list_add(&image->list, &passive_apps);
+
+	sprintf(file, "domain%d-modules", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	image->id = id;
+	list_add(&image->list, &passive_modules);
+
+}
+
+void opd_create_passive(char const *setup_file)
+{
+	FILE *fp;
+	int id=0;
+	char image_kernel[128+1];
+	char range[32+1];
+	char image_xen[128+1];
+	int stat;
+
+	image_kernel[0] = range[0] = image_xen[0] = 0;
+
+	fp = fopen(setup_file, "r");
+
+	if (!fp) {
+		fprintf(stderr, "error: Could not open Xen passive domain "
+			"setup file %s\n", setup_file);
+		exit(EXIT_FAILURE);
+	}
+
+	while (1) {
+		stat = fscanf(fp, "%d %128s %32s %128s", &id, image_kernel, range, 
+			image_xen);
+		if ( stat != 4 )
+			return;
+		opd_create_passive_domain(id, image_kernel, range, image_xen);
+	}
+
+	fclose(fp);
+}
 
 /**
  * Allocate and initialise a kernel image description
@@ -180,6 +291,66 @@
 	struct list_head * pos;
 	struct kernel_image * image = &vmlinux_image;
 
+	if (current_domain != COORDINATOR_DOMAIN) {
+		/* we rely on cpu_mode value (i.e. trans->in_kernel)
+		 * to search the right image type: xen, kernel or user
+		 * We cannot use address ranges since hypervisor does not
+		 * share the same address space with fully virtualized guests,
+		 * and thus address ranges can overlap  */
+		switch ( trans->in_kernel ) {
+
+		/* user mode */
+		case 1:
+			list_for_each(pos, &passive_apps) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			return NULL;
+
+		/* kernel mode */
+		case 2:
+			list_for_each(pos, &passive_vmlinux) {
+				image = list_entry(pos, struct kernel_image, list);
+				if ( (image->id == current_domain)
+				     && ( (image->start == 0 && image->end == 0)
+					  || (image->start <= trans->pc 
+					      && image->end > trans->pc) ) )
+						return image;
+			}
+			/* if not in kernel image range then it should be a module */ 
+			list_for_each(pos, &passive_modules) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			/* This should not happen if the kernel and user level 
+                           oprofile code are sane and in sync */
+			return NULL;
+
+		/* hypervisor mode */
+		case 3:
+			list_for_each(pos, &passive_xen) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain
+				    && image->start <= trans->pc 
+				    && image->end > trans->pc) 
+					return image;
+			}
+			return NULL;
+
+		default:
+			printf("Unexpected error on passive mode: CPU mode is "
+			       "%d for domain %d\n", trans->in_kernel, current_domain);
+			return NULL;
+		}
+		
+		
+	}
+
+	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
+		return &xen_image;
+ 
 	if (no_vmlinux)
 		return image;
 
diff -aur oprofile-0.9.1/daemon/opd_kernel.h oprofile-0.9.1-xen-r3/daemon/opd_kernel.h
--- oprofile-0.9.1/daemon/opd_kernel.h	2003-09-24 14:21:14.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/opd_kernel.h	2006-09-01 09:38:15.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #ifndef OPD_KERNEL_H
@@ -20,6 +23,12 @@
 /** create the kernel image */
 void opd_create_vmlinux(char const * name, char const * arg);
 
+/** create Xen image */
+void opd_create_xen(char const * name, char const * arg);
+
+/** create Xen passive domain images */
+void opd_create_passive(char const *setup_file);
+
 /** opd_reread_module_info - parse /proc/modules for kernel modules */
 void opd_reread_module_info(void);
 
@@ -28,6 +37,7 @@
 	char * name;
 	vma_t start;
 	vma_t end;
+	int id;
 	struct list_head list;
 };
 
diff -aur oprofile-0.9.1/daemon/opd_sfile.c oprofile-0.9.1-xen-r3/daemon/opd_sfile.c
--- oprofile-0.9.1/daemon/opd_sfile.c	2005-05-25 17:00:02.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/opd_sfile.c	2006-09-01 09:38:15.000000000 -0700
@@ -226,7 +226,7 @@
 	}
 
 	/* we might need a kernel image start/end to hash on */
-	if (trans->in_kernel) {
+	else if (trans->in_kernel) {
 		ki = find_kernel_image(trans);
 		if (!ki) {
 			verbprintf(vsamples, "Lost kernel sample %llx\n", trans->pc);
diff -aur oprofile-0.9.1/daemon/opd_trans.c oprofile-0.9.1-xen-r3/daemon/opd_trans.c
--- oprofile-0.9.1/daemon/opd_trans.c	2005-05-25 17:00:02.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/opd_trans.c	2006-09-01 09:38:15.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #include "opd_trans.h"
@@ -24,6 +27,8 @@
 #include <stdio.h>
 #include <errno.h>
 
+int32_t current_domain = COORDINATOR_DOMAIN;
+
 extern size_t kernel_pointer_size;
 
 
@@ -210,6 +215,9 @@
 {
 	verbprintf(vmisc, "KERNEL_ENTER_SWITCH to kernel\n");
 	trans->in_kernel = 1;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	/* subtlety: we must keep trans->cookie cached,
 	 * even though it's meaningless for the kernel -
@@ -219,10 +227,13 @@
 }
 
 
-static void code_kernel_exit(struct transient * trans)
+static void code_user_enter(struct transient * trans)
 {
-	verbprintf(vmisc, "KERNEL_EXIT_SWITCH to user-space\n");
+	verbprintf(vmisc, "USER_ENTER_SWITCH to user-space\n");
 	trans->in_kernel = 0;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	clear_trans_last(trans);
 }
@@ -248,6 +259,37 @@
 	trans->tracing = TRACING_START;
 }
 
+static void code_xen_enter(struct transient *trans)
+{
+	verbprintf(vmisc, "XEN_ENTER_SWITCH to xen\n");
+	trans->in_kernel = 2;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
+	trans->current = NULL;
+	/* subtlety: we must keep trans->cookie cached, even though it's 
+	 * meaningless for Xen - same reason as for kernel 
+	 */
+}
+
+static void code_domain_switch(struct transient *trans)
+{
+	/* While processing passive domain samples we ensure (in_kernel!=0)
+	 * We do this in order to ignore cookies for passive domain samples 
+	 * But, we have to remember the kernel value for coordinator domain, 
+	 * so we do the safe thing: increment when leaving the coordinator
+	 * domain and decrement when returning to it 
+	 */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel++;
+
+	trans->current = NULL;
+	current_domain = (int32_t) pop_buffer_value(trans);
+
+	/* If returning to coordinator domain restore the kernel value */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel--;
+}
 
 typedef void (*handler_t)(struct transient *);
 
@@ -257,11 +299,14 @@
 	&code_cpu_switch,
 	&code_cookie_switch,
 	&code_kernel_enter,
-	&code_kernel_exit,
+ 	&code_user_enter,
 	&code_module_loaded,
 	/* tgid handled differently */
 	&code_unknown,
 	&code_trace_begin,
+	&code_unknown,
+ 	&code_xen_enter,
+	&code_domain_switch,
 };
 
 
diff -aur oprofile-0.9.1/daemon/opd_trans.h oprofile-0.9.1-xen-r3/daemon/opd_trans.h
--- oprofile-0.9.1/daemon/opd_trans.h	2005-05-02 08:06:59.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/opd_trans.h	2006-09-01 09:38:15.000000000 -0700
@@ -15,6 +15,10 @@
 #include "opd_cookie.h"
 #include "op_types.h"
 
+#define COORDINATOR_DOMAIN -1
+
+extern int32_t current_domain;
+
 struct sfile;
 struct anon_mapping;
 
diff -aur oprofile-0.9.1/daemon/oprofiled.c oprofile-0.9.1-xen-r3/daemon/oprofiled.c
--- oprofile-0.9.1/daemon/oprofiled.c	2005-03-29 09:10:51.000000000 -0800
+++ oprofile-0.9.1-xen-r3/daemon/oprofiled.c	2006-09-01 09:38:15.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #include "config.h"
@@ -60,6 +63,10 @@
 int no_vmlinux;
 char * vmlinux;
 char * kernel_range;
+int no_xen;
+char * xenimage;
+char * xen_range;
+char * xen_passive_setup;
 static char * verbose;
 static char * binary_name_filter;
 static char * events;
@@ -75,7 +82,10 @@
 	{ "kernel-range", 'r', POPT_ARG_STRING, &kernel_range, 0, "Kernel VMA range", "start-end", },
 	{ "vmlinux", 'k', POPT_ARG_STRING, &vmlinux, 0, "vmlinux kernel image", "file", },
 	{ "no-vmlinux", 0, POPT_ARG_NONE, &no_vmlinux, 0, "vmlinux kernel image file not available", NULL, },
+	{ "xen-range", 0, POPT_ARG_STRING, &xen_range, 0, "Xen VMA range", "start-end", },
+	{ "xen-image", 0, POPT_ARG_STRING, &xenimage, 0, "Xen image", "file", },
 	{ "image", 0, POPT_ARG_STRING, &binary_name_filter, 0, "image name filter", "profile these comma separated image" },
+	{ "xen-passive-setup", 0, POPT_ARG_STRING, &xen_passive_setup, 0, "Xen passive domain setup file", "filename", },
 	{ "separate-lib", 0, POPT_ARG_INT, &separate_lib, 0, "separate library samples for each distinct application", "[0|1]", },
 	{ "separate-kernel", 0, POPT_ARG_INT, &separate_kernel, 0, "separate kernel samples for each distinct application", "[0|1]", },
 	{ "separate-thread", 0, POPT_ARG_INT, &separate_thread, 0, "thread-profiling mode", "[0|1]" },
@@ -407,7 +417,26 @@
 		poptPrintHelp(optcon, stderr, 0);
 		exit(EXIT_FAILURE);
 	}
-	
+
+	if (!xenimage || !strcmp("", xenimage)) {
+		no_xen = 1;
+	} else {
+ 		no_xen = 0;
+
+		/* canonicalise xen image filename. */
+		tmp = xmalloc(PATH_MAX);
+		if (realpath(xenimage, tmp))
+			xenimage = tmp;
+		else
+			free(tmp);
+
+		if (!xen_range || !strcmp("", xen_range)) {
+			fprintf(stderr, "oprofiled: no Xen VMA range specified.\n");
+			poptPrintHelp(optcon, stderr, 0);
+			exit(EXIT_FAILURE);
+		}
+	}
+
 	opd_parse_events(events);
 
 	opd_parse_image_filter();
diff -aur oprofile-0.9.1/daemon/oprofiled.h oprofile-0.9.1-xen-r3/daemon/oprofiled.h
--- oprofile-0.9.1/daemon/oprofiled.h	2005-04-26 16:49:45.000000000 -0700
+++ oprofile-0.9.1-xen-r3/daemon/oprofiled.h	2006-09-01 09:38:15.000000000 -0700
@@ -7,6 +7,9 @@
  *
  * @author John Levon
  * @author Philippe Elie
+ * Modified by Aravind Menon for Xen
+ * These modifications are:
+ * Copyright (C) 2005 Hewlett-Packard Co.
  */
 
 #ifndef OPROFILED_H
@@ -58,5 +61,9 @@
 extern int no_vmlinux;
 extern char * vmlinux;
 extern char * kernel_range;
+extern int no_xen;
+extern char * xenimage;
+extern char * xen_range;
+extern char * xen_passive_setup;
 
 #endif /* OPROFILED_H */
diff -aur oprofile-0.9.1/doc/opcontrol.1.in oprofile-0.9.1-xen-r3/doc/opcontrol.1.in
--- oprofile-0.9.1/doc/opcontrol.1.in	2005-04-28 14:09:21.000000000 -0700
+++ oprofile-0.9.1-xen-r3/doc/opcontrol.1.in	2006-09-01 09:38:15.000000000 -0700
@@ -105,7 +105,8 @@
 .BI "--callgraph=#depth"
 Enable callgraph sample collection with a maximum depth. Use 0 to disable
 callgraph profiling. This option is currently only usable on x86, using a
-2.6+ kernel with callgraph support enabled.
+2.6+ kernel with callgraph support enabled. This option is not yet supported
+on Xen.
 .br
 .TP
 .BI "--image="[name,name...|"all"]
@@ -129,8 +130,52 @@
 .BI "--kernel-range="start,end
 Set kernel range vma address in hexadecimal.
 
+.SH OPTIONS (specific to Xen)
+.TP
+.BI "--xen="file
+Xen image
+.br
+.TP
+.BI "--active-domains="<list>
+List of domain ids participating in a multi-domain profiling session. 
+Each of the specified domains must run an instance of oprofile. The 
+sequence of opcontrol commands in each domain must follow a given 
+order which is specified in the oprofile user manual. If 
+more than one domain is specified in <list> they should be separated using 
+commas. This option can only be used in domain 0 which is the only domain 
+that can coordinate a multi-domain profiling session. Including domain 0 in 
+the list of active domains is optional. (e.g. --active-domains=2,5,6 and 
+--active-domains=0,2,5,6 are equivalent).
+This option can only be specified
+if --start-daemon is also specified and it is only 
+valid for the current run of the oprofile daemon; e.g. the list 
+of active domains is not persistent.
+.br
+.TP
+.BI "--passive-domains="<list> or "--domains="<list>
+List of domain ids to be profiled, separated by commas. 
+As opposed to the --active-domains option, the domains specified with this
+option do not need to run oprofile. This makes 
+profiling multiple domains easier. However, with the passive-domains option, 
+samples in user level processes and kernel modules cannot be 
+mapped to specific symbols and are aggregated
+under a generic class. Both --active-domains and --passive-domains 
+options can be specified in the same command, but the same domain cannot be
+specified in both options. This option can only be specified if either --start
+or --start-daemon is specified on the same command and it is only valid for 
+the current run of the oprofile daemon; e.g. the list of passive domains is 
+not persistent.
+.br
+.TP
+.BI "--passive-images="<list> or "--domains-images="<list>
+List of kernel images associated with the domains specified in the
+--passive-domains option, also separated by commas. The association
+between the images and domains is based on the order they are
+specified in both options.
+.br
+
 .SH ENVIRONMENT
-No special environment variables are recognised by opreport.
+No special environment variables are recognised by opcontrol.
 
 .SH FILES
 .TP
diff -aur oprofile-0.9.1/utils/opcontrol oprofile-0.9.1-xen-r3/utils/opcontrol
--- oprofile-0.9.1/utils/opcontrol	2005-06-16 12:12:07.000000000 -0700
+++ oprofile-0.9.1-xen-r3/utils/opcontrol	2006-09-01 09:38:16.000000000 -0700
@@ -144,6 +144,17 @@
    --buffer-size=num             kernel buffer size in sample units
    --cpu-buffer-size=num         per-cpu buffer size in units (2.6 only)
    --note-table-size             kernel notes buffer size in notes units (2.4 only)
+
+   --xen=file                    Xen image (for Xen only)
+   --active-domains=id[,ids]     list of domains in multiple domain profiling session (Xen)
+                                 (detailed profiling of user level and kernel modules code)
+                                 (requires running oprofile on these domains)
+   --passive-domains=id[,ids]    list of domains to be profiled (Xen).
+     or --domains=id[,ids]       (coarse profiling of user level and kernel modules code)
+                                 (no need to run oprofile on these domains)
+   --passive-images=file[,files] list of kernel images associated with each passive domain
+     or 
+   --domain-images=file[,files]
 " >&2
 }
 
@@ -246,6 +257,7 @@
 	CPU_BUF_SIZE=0
 	NOTE_SIZE=0
 	VMLINUX=
+	XENIMAGE="none"
 	VERBOSE=""
 	SEPARATE_LIB=0
 	SEPARATE_KERNEL=0
@@ -259,6 +271,9 @@
 	SETUP_DIR="/root/.oprofile"
 	SETUP_FILE="$SETUP_DIR/daemonrc"
 
+	# location for passing info about passive domains to daemon
+	PASSIVE_SETUP_FILE="$SETUP_DIR/xendomain.setup"
+
 	CPUTYPE=`cat $MOUNT/cpu_type`
 	OP_COUNTERS=`ls $MOUNT/ | grep "^[0-9]\+\$" | tr "\n" " "`
 	NR_CHOSEN=0
@@ -326,6 +341,7 @@
 		echo "NOTE_SIZE=$NOTE_SIZE" >> $SETUP_FILE
 	fi
 	echo "CALLGRAPH=$CALLGRAPH" >> $SETUP_FILE
+	echo "XENIMAGE=$XENIMAGE" >> $SETUP_FILE
 }
 
 
@@ -363,7 +379,7 @@
 }
 
 
-check_valid_args()
+check_valid_vmlinux()
 {
 	if test -z "$VMLINUX"; then
 		echo "No vmlinux file specified. You must specify the correct vmlinux file, e.g." >&2
@@ -387,34 +403,134 @@
 }
 
 
-# get start and end points of the kernel
-get_kernel_range()
+# similar check for Xen image
+check_valid_xen()
 {
-	if test ! -z "$KERNEL_RANGE"; then
-		return;
+	if test -f "$XENIMAGE"; then
+		return
 	fi
 
-	if test "$VMLINUX" = "none"; then
+	if test "$XENIMAGE" = "none"; then
+		return
+	fi
+
+	echo "The specified XenImage file \"$XENIMAGE\" does not exist." >&2
+	exit 1
+}
+
+
+# get start and end points of a file image (linux kernel or xen)
+# get_image_range parameter: $1=type_of_image (linux or xen)
+get_image_range()
+{
+	if test "$1" = "xen"; then
+		if test ! -z "$XEN_RANGE"; then
+			return;
+		fi
+		FILE_IMAGE="$XENIMAGE"
+	else
+		if test ! -z "$KERNEL_RANGE"; then
+			return;
+		fi
+		FILE_IMAGE="$VMLINUX"
+	fi
+
+	if test "$FILE_IMAGE" = "none"; then
 		return;
 	fi
 
 	# start at the start of .text and then continue to the end 
-	range_info=`objdump -h $VMLINUX 2>/dev/null | grep " .text "`
+	range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
 	tmp1=`echo $range_info | awk '{print $4}'`	
 	tmp_length=`echo $range_info | awk  '{print $3}'`
-	tmp2=`objdump -h $VMLINUX --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
+	tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
 
 	if test -z "$tmp1" -o -z "$tmp2"; then
-		echo "The specified file $VMLINUX does not seem to be valid" >&2
-		echo "Make sure you are using vmlinux not vmlinuz" >&2
+		echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
+		echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
 		vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
 		exit 1
 	fi
 
-	KERNEL_RANGE="`echo $tmp1`,`echo $tmp2`"
-	vecho "KERNEL_RANGE $KERNEL_RANGE"
+	if test "$1" = "xen"; then
+		XEN_RANGE="`echo $tmp1`,`echo $tmp2`"
+		vecho "XEN_RANGE $XEN_RANGE"
+	else
+		KERNEL_RANGE="`echo $tmp1`,`echo $tmp2`"
+		vecho "KERNEL_RANGE $KERNEL_RANGE"
+	fi
 }
  
+set_passive_domain()
+{
+	DOMAIN_ID=$1
+	FILE_IMAGE=$2
+	XEN_IMAGE=$3
+
+	if test "$FILE_IMAGE" = "none"; then
+		RANGE="0,0"
+		FILE_IMAGE="domain$DOMAIN_ID-kernel"
+	else
+		# Find VMA range for passive domain kernel image 
+		range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
+		tmp1=`echo $range_info | awk '{print $4}'`	
+		tmp_length=`echo $range_info | awk  '{print $3}'`
+		tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
+
+		if test -z "$tmp1" -o -z "$tmp2"; then
+			echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
+			echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
+			vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
+			exit 1
+		fi
+		RANGE="`echo $tmp1`,`echo $tmp2`"
+	fi
+	echo " $DOMAIN_ID $FILE_IMAGE $RANGE $XEN_IMAGE" >> $PASSIVE_SETUP_FILE
+}
+
+
+set_passive_domain_config()
+{
+
+	create_dir "$SETUP_DIR"
+
+	touch $PASSIVE_SETUP_FILE
+	chmod 644 $PASSIVE_SETUP_FILE
+	>$PASSIVE_SETUP_FILE
+
+	NDOMAINS=`echo "$PASSIVE_DOMAINS" | awk -F',' '{print NF}'`
+
+	if test -n "$PASSIVE_IMAGES"; then
+		NIMAGES=`echo "$PASSIVE_IMAGES" | awk -F',' '{print NF}'`
+		if [ $NDOMAINS != $NIMAGES ]; then
+			echo "# of passive domains and # of passive images doesn't match." >&2
+			do_help
+			exit 1
+		fi
+
+		for (( i=1; i<=$NDOMAINS; i++ )); do
+			ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+			FILE=`echo "$PASSIVE_IMAGES" | awk -F',' '{print $'$i'}'`
+			if test ! -f "$FILE"; then
+				echo "Image $FILE for passive domain $ID not found." >&2
+				return 1
+			fi
+			LNK_KERNEL=/boot/domain$ID-kernel
+			ln -sf $FILE $LNK_KERNEL
+			LNK_XEN=/boot/domain$ID-xen
+			ln -sf $XENIMAGE $LNK_XEN
+			set_passive_domain $ID $LNK_KERNEL $LNK_XEN 
+		done
+	else
+			for (( i=1; i<=$NDOMAINS; i++ )); do
+				ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+				LNK_XEN=/boot/domain$ID-xen
+				set_passive_domain $ID none $LNK_XEN
+		done 
+
+	fi
+}
+
  
 # validate --separate= parameters. This function is called with IFS=,
 # so on each argument is splitted
@@ -692,7 +808,7 @@
 				VMLINUX=$val
 				DO_SETUP=yes
 				# check validity
-				get_kernel_range
+				get_image_range "linux"
 				;;
 			--no-vmlinux)
 				VMLINUX=none
@@ -703,6 +819,27 @@
 				KERNEL_RANGE=$val
 				DO_SETUP=yes
 				;;
+			--xen)
+				error_if_empty $arg $val
+				XENIMAGE=$val
+				DO_SETUP=yes
+				get_image_range "xen"
+				;;
+			--active-domains)
+				error_if_empty $arg $val
+				ACTIVE_DOMAINS=$val
+				DO_SETUP=yes
+				;;
+			--passive-domains|--domains)
+				error_if_empty $arg $val
+				PASSIVE_DOMAINS=$val
+				DO_SETUP=yes
+				;;
+			--passive-images|--domain-images)
+				error_if_empty $arg $val
+				PASSIVE_IMAGES=$val
+				DO_SETUP=yes
+				;;
 			--note-table-size)
 				error_if_empty $arg $val
 				if test $"KERNEL_SUPPORT" = "yes"; then
@@ -775,6 +912,16 @@
 			exit 1
 		fi
 	fi
+
+	if test -n "$ACTIVE_DOMAINS" -a "$START_DAEMON" != "yes"; then
+		echo "Option \"--active-domains\" can only be used with option \"-start-daemon\"." >&2
+		exit 1
+	fi
+
+	if test -n "$PASSIVE_DOMAINS" -a "$START_DAEMON" != "yes" -a "$START" != "yes"; then
+		echo "Option \"--passive-domains\" or "--domains" can only be used with option \"--start-daemon\" or \"--start\"." >&2
+		exit 1
+	fi
 }
 
 
@@ -974,6 +1121,23 @@
 		fi
 	fi
 
+	if test -n "$ACTIVE_DOMAINS"; then
+		if test "$KERNEL_SUPPORT" = "yes"; then
+			echo $ACTIVE_DOMAINS >$MOUNT/active_domains
+		else
+			echo "active-domains not supported - ignored" >&2
+		fi
+	fi
+
+	if test -n "$PASSIVE_DOMAINS"; then
+		if test "$KERNEL_SUPPORT" = "yes"; then
+			echo $PASSIVE_DOMAINS >$MOUNT/passive_domains
+			set_passive_domain_config
+		else
+			echo "passive-domains not supported - ignored" >&2
+		fi
+	fi
+	
 	if test $NOTE_SIZE != 0; then
 		set_param notesize $NOTE_SIZE
 	fi
@@ -1066,8 +1230,10 @@
  
 	do_setup
 	do_load_setup
-	check_valid_args
-	get_kernel_range
+	check_valid_vmlinux
+	check_valid_xen
+	get_image_range "linux"
+	get_image_range "xen"
 	do_param_setup
 
 	OPD_ARGS=" \
@@ -1084,10 +1250,18 @@
 		OPD_ARGS="$OPD_ARGS --vmlinux=$VMLINUX --kernel-range=$KERNEL_RANGE"
 	fi
 
+	if ! test "$XENIMAGE" = "none"; then
+		OPD_ARGS="$OPD_ARGS --xen-image=$XENIMAGE --xen-range=$XEN_RANGE"
+	fi
+ 
 	if ! test -z "$IMAGE_FILTER"; then
 		OPD_ARGS="$OPD_ARGS --image=$IMAGE_FILTER"
 	fi
 
+	if ! test -z "$PASSIVE_DOMAINS"; then
+		OPD_ARGS="$OPD_ARGS --xen-passive-setup=$PASSIVE_SETUP_FILE"
+	fi
+
 	if test -n "$VERBOSE"; then
 		OPD_ARGS="$OPD_ARGS --verbose=$VERBOSE"
 	fi
@@ -1294,6 +1468,8 @@
 	move_and_remove $SAMPLES_DIR/current/{root}
 
 	hup_daemon
+
+	rm -f /boot/domain-*-kernel /boot/domain-*-xen
 }
 
 
@@ -1324,7 +1500,8 @@
 	fi
  
 	if test "$SETUP" = "yes"; then
-		check_valid_args
+		check_valid_vmlinux
+		check_valid_xen
 		do_save_setup
 	fi
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [XENOPROLIFE] New oprofile patch for XenOProfile

[William Cohen]

Santos, Jose Renato G wrote:
> Tom,
> 
> Thanks for the HVM patches.
> This is good news
> 
> We are now able to profile HVM guests (both SVM and VT)(in passive mode)
> using Tom's patches combined with the attached new version of oprofile.
> The attached patch (r3) combines the old oprofile patch (r2) with the
> patch "oprofile-0.9.1-fix-hvm-addr-overlap.patch" that Tom mentioned and
> included in his post.
> After Tom's fixes are merged, this is the only patch that will be
> needed.
> 
> The patch is for oprofile 0.9.1. Oprofile 0.9.2, which will be release
> soon, will include XenOprofile support for active domains but it will
> not support passive domains. I will generate a patch with passive domain
> support for oprofile 0.9.2 when it is released.
> 
> I hope Tom patches are accepted and make into Xen 3.0.3
> 
> Thanks
> 
> Renato

Hi all,

OProfile 0.9.2 was released this past Friday, Sept 15. It is available on the 
OProfile website:

http://oprofile.sourceforge.net/news/

-Will

XenOProfile patch for Oprofile 0.9.2

[Santos, Jose Renato G]

 
A XenOprofile patch for Oprofile 0.9.2 is now available at
http://xenoprof.sourceforge.net.
Oprofile 0.9.2 already supports XenOprofile but it does not include
support for passive domain profiling.
This patch adds passive domain profiling support to Oprofile 0.9.2. 

This version is more recent than the one posted by William Cohen last
week. It includes the latest fixes to support fully vitrualized guests. 

This patch is equivalent to the latest patch for Oprofile 0.9.1
(oprofile-0.9.1-xen-r3.patch) ported to 0.9.2.

Renato


> -----Original Message-----
> From: William Cohen [mailto:wcohen@redhat.com] 
> Sent: Monday, September 18, 2006 11:29 AM
> To: Santos, Jose Renato G
> Cc: Woller, Thomas; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> XenOProfile
> 
> 
> Hi all,
> 
> OProfile 0.9.2 was released this past Friday, Sept 15. It is 
> available on the OProfile website:
> 
> http://oprofile.sourceforge.net/news/
> 
> -Will
> 

Re: [XENOPROLIFE] New oprofile patch for XenOProfile

[Ray Bryant]

Renato,

Well, I'd postponed any work with xenoprof until we had a working 3.0.3 
version plus the local patches that we are using (includes the xenoprof 
patches that Tom Woller et al have done).

So, I'm now working with an oprofile 0.9.2 plus your patch 
oprofile-0.9.2-xen.patch from the HP open source website.   The particular 
project we are working on requires us to obtain profiles for the HVM guest 
kernel.   Unfortunately, my first few tries at this have been unsuccessful (I 
get lots of "lost kernel sample" messages in the oprofiled.log and no 
reported samples for the guest kernel.  :-(  ).

So I guess my guestion to you is, do you have access to a VT or AMD V enabled 
platform that you can test stuff on?   (I'd like to find a collegue to work 
with on this problem if at all possible.)   I have dedicated VT and AMD 
platforms for my use, so if you have a VT platorm, we can get stuff to work 
correctly there first and then I can work with Tom et al to get the AMD V 
versions to work.

-- 
Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Santos, Jose Renato G]

Ray,

I have an AMD machine in my Lab which I believe has SVM support.
I can use that if needed, but I will need sometime to get it ready and
running Xen.
I thought Tom has tested oprofile with both AMD and Intel HVM guests and
that things were working fine.
Could you please sync up with Tom and make sure it is not a problem with
your configuration.
Tom can you confirm you were able to successfully run XenOprofile for
HVM guests?
If needed I can try to reproduce your problem here when I have my AMD
machine up.

Regards

Renato 

> -----Original Message-----
> From: Ray Bryant [mailto:raybry@mpdtxmail.amd.com] 
> Sent: Tuesday, November 07, 2006 9:25 AM
> To: xen-devel@lists.xensource.com
> Cc: Santos, Jose Renato G; Woller, Thomas
> Subject: Re: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> XenOProfile
> 
> Renato,
> 
> Well, I'd postponed any work with xenoprof until we had a 
> working 3.0.3 version plus the local patches that we are 
> using (includes the xenoprof patches that Tom Woller et al have done).
> 
> So, I'm now working with an oprofile 0.9.2 plus your patch 
> oprofile-0.9.2-xen.patch from the HP open source website.   
> The particular 
> project we are working on requires us to obtain profiles for 
> the HVM guest 
> kernel.   Unfortunately, my first few tries at this have been 
> unsuccessful (I 
> get lots of "lost kernel sample" messages in the 
> oprofiled.log and no reported samples for the guest kernel.  :-(  ).
> 
> So I guess my guestion to you is, do you have access to a VT 
> or AMD V enabled 
> platform that you can test stuff on?   (I'd like to find a 
> collegue to work 
> with on this problem if at all possible.)   I have dedicated 
> VT and AMD 
> platforms for my use, so if you have a VT platorm, we can get 
> stuff to work correctly there first and then I can work with 
> Tom et al to get the AMD V versions to work.
> 
> --
> Ray Bryant
> AMD Performance Labs                   Austin, Tx
> 512-602-0038 (o)                 512-507-7807 (c)
> 
> 
> 

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Woller, Thomas]

> I have an AMD machine in my Lab which I believe has SVM support.
> I can use that if needed, but I will need sometime to get it 
> ready and running Xen.
> I thought Tom has tested oprofile with both AMD and Intel HVM 
> guests and that things were working fine.
thanks renato, I believe that the hypervisor portion of xenoprofile is
sending
the correct mode, eip/rip values.  I'll get with Ray and see if we can
track
down where the issue might be (oprofile or hv, or configuration issue). 

> Could you please sync up with Tom and make sure it is not a 
> problem with your configuration.
> Tom can you confirm you were able to successfully run 
> XenOprofile for HVM guests?
> If needed I can try to reproduce your problem here when I 
> have my AMD machine up.
We'll definitely let you know if we need some assistance in the oprofile
area.  
Any idea when will 0.9.3 be out?  I know that some of the distros are 
trying to add your xenoprofile patch on top of 0.9.2 for their releases,
and having 0.9.3 would be easier that already contained the xen patches.
 
  --Tom

> 
> Regards
> 
> Renato 
> 
> > -----Original Message-----
> > From: Ray Bryant [mailto:raybry@mpdtxmail.amd.com]
> > Sent: Tuesday, November 07, 2006 9:25 AM
> > To: xen-devel@lists.xensource.com
> > Cc: Santos, Jose Renato G; Woller, Thomas
> > Subject: Re: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> > XenOProfile
> > 
> > Renato,
> > 
> > Well, I'd postponed any work with xenoprof until we had a working 
> > 3.0.3 version plus the local patches that we are using 
> (includes the 
> > xenoprof patches that Tom Woller et al have done).
> > 
> > So, I'm now working with an oprofile 0.9.2 plus your patch 
> > oprofile-0.9.2-xen.patch from the HP open source website.   
> > The particular
> > project we are working on requires us to obtain profiles 
> for the HVM 
> > guest
> > kernel.   Unfortunately, my first few tries at this have been 
> > unsuccessful (I
> > get lots of "lost kernel sample" messages in the 
> oprofiled.log and no 
> > reported samples for the guest kernel.  :-(  ).
> > 
> > So I guess my guestion to you is, do you have access to a 
> VT or AMD V 
> > enabled
> > platform that you can test stuff on?   (I'd like to find a 
> > collegue to work 
> > with on this problem if at all possible.)   I have dedicated 
> > VT and AMD
> > platforms for my use, so if you have a VT platorm, we can 
> get stuff to 
> > work correctly there first and then I can work with Tom et 
> al to get 
> > the AMD V versions to work.
> > 
> > --
> > Ray Bryant
> > AMD Performance Labs                   Austin, Tx
> > 512-602-0038 (o)                 512-507-7807 (c)
> > 
> > 
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Santos, Jose Renato G]

 

> -----Original Message-----
> From: Woller, Thomas [mailto:thomas.woller@amd.com] 
> Sent: Wednesday, November 08, 2006 7:12 AM
> To: Santos, Jose Renato G; Ray Bryant; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> XenOProfile
> 
> > I have an AMD machine in my Lab which I believe has SVM support.
> > I can use that if needed, but I will need sometime to get 
> it ready and 
> > running Xen.
> > I thought Tom has tested oprofile with both AMD and Intel 
> HVM guests 
> > and that things were working fine.
> thanks renato, I believe that the hypervisor portion of 
> xenoprofile is sending the correct mode, eip/rip values.  
> I'll get with Ray and see if we can track down where the 
> issue might be (oprofile or hv, or configuration issue). 
> 

Ok. That seems a good plan.
I will be glad to help if I can when you have more details.
On a related note, I received a report that XenOprofile is missing some
user level samples. I am preparing a patch with the fix and should post
it to the list later today. This should affect kernel samples though.

> > Could you please sync up with Tom and make sure it is not a problem 
> > with your configuration.
> > Tom can you confirm you were able to successfully run 
> XenOprofile for 
> > HVM guests?
> > If needed I can try to reproduce your problem here when I 
> have my AMD 
> > machine up.
> We'll definitely let you know if we need some assistance in 
> the oprofile area.  
> Any idea when will 0.9.3 be out?  I know that some of the 
> distros are trying to add your xenoprofile patch on top of 
> 0.9.2 for their releases, and having 0.9.3 would be easier 
> that already contained the xen patches.

No I don't know when 0.9.3 wil be out. I still need to sync up with
William Cohen to get the passive domain patches into the oprofile CVS
tree. I was waiting to finish some cleanups in the patch before sending
it to him, but I did not have had time to work on this yet.  

Regards  

Renato

>  
>   --Tom
> 
> > 
> > Regards
> > 
> > Renato
> > 
> > > -----Original Message-----
> > > From: Ray Bryant [mailto:raybry@mpdtxmail.amd.com]
> > > Sent: Tuesday, November 07, 2006 9:25 AM
> > > To: xen-devel@lists.xensource.com
> > > Cc: Santos, Jose Renato G; Woller, Thomas
> > > Subject: Re: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> > > XenOProfile
> > > 
> > > Renato,
> > > 
> > > Well, I'd postponed any work with xenoprof until we had a working
> > > 3.0.3 version plus the local patches that we are using
> > (includes the
> > > xenoprof patches that Tom Woller et al have done).
> > > 
> > > So, I'm now working with an oprofile 0.9.2 plus your patch 
> > > oprofile-0.9.2-xen.patch from the HP open source website.   
> > > The particular
> > > project we are working on requires us to obtain profiles
> > for the HVM
> > > guest
> > > kernel.   Unfortunately, my first few tries at this have been 
> > > unsuccessful (I
> > > get lots of "lost kernel sample" messages in the
> > oprofiled.log and no
> > > reported samples for the guest kernel.  :-(  ).
> > > 
> > > So I guess my guestion to you is, do you have access to a
> > VT or AMD V
> > > enabled
> > > platform that you can test stuff on?   (I'd like to find a 
> > > collegue to work 
> > > with on this problem if at all possible.)   I have dedicated 
> > > VT and AMD
> > > platforms for my use, so if you have a VT platorm, we can
> > get stuff to
> > > work correctly there first and then I can work with Tom et
> > al to get
> > > the AMD V versions to work.
> > > 
> > > --
> > > Ray Bryant
> > > AMD Performance Labs                   Austin, Tx
> > > 512-602-0038 (o)                 512-507-7807 (c)
> > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> > 
> > 
> 
> 
> 

[PATCH] XENOPROLIFE. Bug fix for missing passive domain user leval samples

[Santos, Jose Renato G]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

 
Oprofile user level samples for passive domains are being lost.
The number of of lost samples is most significant when dom0 is idle.   
This patch fix the bug

Thanks

Renato

[-- Attachment #2: xenoprof_fix_passive_user_missing-11760.patch --]
[-- Type: application/octet-stream, Size: 8584 bytes --]

diff -r 4a5a7bb30e83 patches/linux-2.6.16.29/xenoprof-generic.patch
--- a/patches/linux-2.6.16.29/xenoprof-generic.patch	Mon Nov  6 08:38:33 2006 -0800
+++ b/patches/linux-2.6.16.29/xenoprof-generic.patch	Mon Nov  6 15:49:16 2006 -0800
@@ -1,6 +1,6 @@ diff -pruN ../orig-linux-2.6.16.29/drive
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/buffer_sync.c ./drivers/oprofile/buffer_sync.c
---- ../orig-linux-2.6.16.29/drivers/oprofile/buffer_sync.c	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/buffer_sync.c	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/buffer_sync.c	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/buffer_sync.c	2006-11-06 15:16:52.000000000 -0800
 @@ -6,6 +6,10 @@
   *
   * @author John Levon <levon@movementarian.org>
@@ -12,7 +12,27 @@ diff -pruN ../orig-linux-2.6.16.29/drive
   * This is the core of the buffer management. Each
   * CPU buffer is processed and entered into the
   * global event buffer. Such processing is necessary
-@@ -275,15 +279,31 @@ static void add_cpu_switch(int i)
+@@ -38,6 +42,7 @@ static cpumask_t marked_cpus = CPU_MASK_
+ static DEFINE_SPINLOCK(task_mortuary);
+ static void process_task_mortuary(void);
+ 
++static int cpu_current_domain[NR_CPUS];
+ 
+ /* Take ownership of the task struct and place it on the
+  * list for processing. Only after two full buffer syncs
+@@ -146,6 +151,11 @@ static void end_sync(void)
+ int sync_start(void)
+ {
+ 	int err;
++	int i;
++
++	for (i = 0; i < NR_CPUS; i++) {
++		cpu_current_domain[i] = COORDINATOR_DOMAIN;
++	}
+ 
+ 	start_cpu_work();
+ 
+@@ -275,15 +285,31 @@ static void add_cpu_switch(int i)
  	last_cookie = INVALID_COOKIE;
  }
  
@@ -50,7 +70,7 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  static void
  add_user_ctx_switch(struct task_struct const * task, unsigned long cookie)
  {
-@@ -348,9 +368,9 @@ static int add_us_sample(struct mm_struc
+@@ -348,9 +374,9 @@ static int add_us_sample(struct mm_struc
   * for later lookup from userspace.
   */
  static int
@@ -62,7 +82,7 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  		add_sample_entry(s->eip, s->event);
  		return 1;
  	} else if (mm) {
-@@ -496,10 +516,11 @@ void sync_buffer(int cpu)
+@@ -496,15 +522,21 @@ void sync_buffer(int cpu)
  	struct mm_struct *mm = NULL;
  	struct task_struct * new;
  	unsigned long cookie = 0;
@@ -75,7 +95,17 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  
  	down(&buffer_sem);
   
-@@ -512,16 +533,18 @@ void sync_buffer(int cpu)
+ 	add_cpu_switch(cpu);
+ 
++	/* We need to assign the first samples in this CPU buffer to the
++	   same domain that we were processing at the last sync_buffer */
++	if (cpu_current_domain[cpu] != COORDINATOR_DOMAIN) {
++		add_domain_switch(cpu_current_domain[cpu]);
++	}
+ 	/* Remember, only we can modify tail_pos */
+ 
+ 	available = get_slots(cpu_buf);
+@@ -512,16 +544,18 @@ void sync_buffer(int cpu)
  	for (i = 0; i < available; ++i) {
  		struct op_sample * s = &cpu_buf->buffer[cpu_buf->tail_pos];
   
@@ -99,7 +129,7 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  			} else {
  				struct mm_struct * oldmm = mm;
  
-@@ -535,11 +558,16 @@ void sync_buffer(int cpu)
+@@ -535,11 +569,21 @@ void sync_buffer(int cpu)
  				add_user_ctx_switch(new, cookie);
  			}
  		} else {
@@ -109,10 +139,15 @@ diff -pruN ../orig-linux-2.6.16.29/drive
 -					state = sb_bt_ignore;
 -					atomic_inc(&oprofile_stats.bt_lost_no_mapping);
 +			if (domain_switch) {
++				cpu_current_domain[cpu] = s->eip;
 +				add_domain_switch(s->eip);
 +				domain_switch = 0;
 +			} else {
-+				if (state >= sb_bt_start &&
++				if (cpu_current_domain[cpu] !=
++				    COORDINATOR_DOMAIN) {
++					add_sample_entry(s->eip, s->event);
++				}
++				else  if (state >= sb_bt_start &&
 +				    !add_sample(mm, s, cpu_mode)) {
 +					if (state == sb_bt_start) {
 +						state = sb_bt_ignore;
@@ -121,9 +156,21 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  				}
  			}
  		}
+@@ -548,6 +592,11 @@ void sync_buffer(int cpu)
+ 	}
+ 	release_mm(mm);
+ 
++	/* We reset domain to COORDINATOR at each CPU switch */
++	if (cpu_current_domain[cpu] != COORDINATOR_DOMAIN) {
++		add_domain_switch(COORDINATOR_DOMAIN);
++	}
++
+ 	mark_done(cpu);
+ 
+ 	up(&buffer_sem);
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.c ./drivers/oprofile/cpu_buffer.c
---- ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.c	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/cpu_buffer.c	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.c	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/cpu_buffer.c	2006-11-06 14:47:55.000000000 -0800
 @@ -6,6 +6,10 @@
   *
   * @author John Levon <levon@movementarian.org>
@@ -233,8 +280,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
   * This serves to avoid cpu buffer overflow, and makes sure
   * the task mortuary progresses
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.h ./drivers/oprofile/cpu_buffer.h
---- ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.h	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/cpu_buffer.h	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/cpu_buffer.h	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/cpu_buffer.h	2006-11-06 14:47:55.000000000 -0800
 @@ -36,7 +36,7 @@ struct oprofile_cpu_buffer {
  	volatile unsigned long tail_pos;
  	unsigned long buffer_size;
@@ -258,8 +305,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  
  #endif /* OPROFILE_CPU_BUFFER_H */
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/event_buffer.h ./drivers/oprofile/event_buffer.h
---- ../orig-linux-2.6.16.29/drivers/oprofile/event_buffer.h	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/event_buffer.h	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/event_buffer.h	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/event_buffer.h	2006-11-06 14:47:55.000000000 -0800
 @@ -29,15 +29,20 @@ void wake_up_buffer_waiter(void);
  #define CPU_SWITCH_CODE 		2
  #define COOKIE_SWITCH_CODE 		3
@@ -283,8 +330,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  void add_event_entry(unsigned long data);
   
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/oprof.c ./drivers/oprofile/oprof.c
---- ../orig-linux-2.6.16.29/drivers/oprofile/oprof.c	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/oprof.c	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/oprof.c	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/oprof.c	2006-11-06 14:47:55.000000000 -0800
 @@ -5,6 +5,10 @@
   * @remark Read the file COPYING
   *
@@ -339,8 +386,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  {
  	int err;
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/oprof.h ./drivers/oprofile/oprof.h
---- ../orig-linux-2.6.16.29/drivers/oprofile/oprof.h	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/oprof.h	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/oprof.h	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/oprof.h	2006-11-06 14:47:55.000000000 -0800
 @@ -35,5 +35,8 @@ void oprofile_create_files(struct super_
  void oprofile_timer_init(struct oprofile_operations * ops);
  
@@ -351,8 +398,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
   
  #endif /* OPROF_H */
 diff -pruN ../orig-linux-2.6.16.29/drivers/oprofile/oprofile_files.c ./drivers/oprofile/oprofile_files.c
---- ../orig-linux-2.6.16.29/drivers/oprofile/oprofile_files.c	2006-09-12 19:02:10.000000000 +0100
-+++ ./drivers/oprofile/oprofile_files.c	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/drivers/oprofile/oprofile_files.c	2006-11-06 14:46:52.000000000 -0800
++++ ./drivers/oprofile/oprofile_files.c	2006-11-06 14:47:55.000000000 -0800
 @@ -5,15 +5,21 @@
   * @remark Read the file COPYING
   *
@@ -581,8 +628,8 @@ diff -pruN ../orig-linux-2.6.16.29/drive
  	oprofilefs_create_ulong(sb, root, "buffer_size", &fs_buffer_size);
  	oprofilefs_create_ulong(sb, root, "buffer_watershed", &fs_buffer_watershed);
 diff -pruN ../orig-linux-2.6.16.29/include/linux/oprofile.h ./include/linux/oprofile.h
---- ../orig-linux-2.6.16.29/include/linux/oprofile.h	2006-09-12 19:02:10.000000000 +0100
-+++ ./include/linux/oprofile.h	2006-09-19 14:06:05.000000000 +0100
+--- ../orig-linux-2.6.16.29/include/linux/oprofile.h	2006-11-06 14:46:42.000000000 -0800
++++ ./include/linux/oprofile.h	2006-11-06 14:47:55.000000000 -0800
 @@ -16,6 +16,8 @@
  #include <linux/types.h>
  #include <linux/spinlock.h>

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [XENOPROLIFE] New oprofile patch for XenOProfile

[Ray Bryant]

On Wednesday 08 November 2006 10:54, Santos, Jose Renato G wrote:

>
> Ok. That seems a good plan.
> I will be glad to help if I can when you have more details.
> On a related note, I received a report that XenOprofile is missing some
> user level samples. I am preparing a patch with the fix and should post
> it to the list later today. This should affect kernel samples though.
>

"should" or "should not" affect kernel samples?

I went back through my old tests and the last time I had a good profile output 
was with change set 10650 in September.

<snip>

-- 
Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Santos, Jose Renato G]

 

> -----Original Message-----
> From: Ray Bryant [mailto:raybry@mpdtxmail.amd.com] 
> Sent: Wednesday, November 08, 2006 11:23 AM
> To: Santos, Jose Renato G
> Cc: Woller, Thomas; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> XenOProfile
> 
> On Wednesday 08 November 2006 10:54, Santos, Jose Renato G wrote:
> 
> >
> > Ok. That seems a good plan.
> > I will be glad to help if I can when you have more details.
> > On a related note, I received a report that XenOprofile is missing 
> > some user level samples. I am preparing a patch with the fix and 
> > should post it to the list later today. This should affect 
> kernel samples though.
> >
> 
> "should" or "should not" affect kernel samples?
> 

Sorry for the typo. It should NOT affect kernel samples
REnato 

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Bryant, Ray]

Santos, Jose Renato G wrote:

<snip>

>>> 
>>> Ok. That seems a good plan.
>>> I will be glad to help if I can when you have more details.
>>> On a related note, I received a report that XenOprofile is missing
>>> some user level samples. I am preparing a patch with the fix and
>>> should post it to the list later today. This should affect kernel
>>> samples though. 
>>> 
>> 
>> "should" or "should not" affect kernel samples?
>> 
> 
> Sorry for the typo. It should NOT affect kernel samples REnato

That's what I figured, but was just checking.  :-)

I mispoke before, the last time I have this stuff working was with cs
11408 and what I labeled "old profile" (whatever that was...)

So I went back and resurrected my cs 11408 xen build and ran three
different versions of xenoprof against it:

(1)  oprofile 0.9.2 + your patch for 0.9.2
(2)  oprofile 0.9.1 + your patch r3 for 0.9.1
(3)  oprofile 0.9.1 + Rosimildo's old patch to fix image->start and
image->end for 64 bit hypervisor

(1) and (2) didn't give me any xen or guest kernel samples.   (3) worked
the way I was expecting things to work (as it had before).
So I am guessing that (3) is the old profile I used before.

I rebooted to cs 11785 + AMD patches, and retried (3) and it works
basically  the same as it did for 11408 (whew).  I still haven't
verified that the xen and kernel guest samples are correct, but at least
there are xen, kernel guest, kernel user samples and I'm not getting any
with (1) or (2).

So I am thinking that the problems I am seeing are related to 64-bit
hypervisor and the more recent fixes than Rosimildo's patchset.

-- 
Best Regards,

Ray

Ray Bryant, Ph. D.
x50038 or  512-602-0038
AMD Performance Labs
Austin, Texas

RE: [XENOPROLIFE] New oprofile patch for XenOProfile

[Santos, Jose Renato G]

 Ray,

 Do you get versions 1 and 2 working with 32bit Xen?
 Could you please send me Rosimildo patches. I don't think I have it and
I would like to compare with the others.
 Thanks

  Renato 

> -----Original Message-----
> From: Bryant, Ray [mailto:ray.bryant@amd.com] 
> Sent: Wednesday, November 08, 2006 1:01 PM
> To: Santos, Jose Renato G; Ray Bryant
> Cc: Woller, Thomas; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [XENOPROLIFE] New oprofile patch for 
> XenOProfile
> 
> Santos, Jose Renato G wrote:
> 
> <snip>
> 
> >>> 
> >>> Ok. That seems a good plan.
> >>> I will be glad to help if I can when you have more details.
> >>> On a related note, I received a report that XenOprofile 
> is missing 
> >>> some user level samples. I am preparing a patch with the fix and 
> >>> should post it to the list later today. This should affect kernel 
> >>> samples though.
> >>> 
> >> 
> >> "should" or "should not" affect kernel samples?
> >> 
> > 
> > Sorry for the typo. It should NOT affect kernel samples REnato
> 
> That's what I figured, but was just checking.  :-)
> 
> I mispoke before, the last time I have this stuff working was with cs
> 11408 and what I labeled "old profile" (whatever that was...)
> 
> So I went back and resurrected my cs 11408 xen build and ran 
> three different versions of xenoprof against it:
> 
> (1)  oprofile 0.9.2 + your patch for 0.9.2
> (2)  oprofile 0.9.1 + your patch r3 for 0.9.1
> (3)  oprofile 0.9.1 + Rosimildo's old patch to fix image->start and
> image->end for 64 bit hypervisor
> 
> (1) and (2) didn't give me any xen or guest kernel samples.   
> (3) worked
> the way I was expecting things to work (as it had before).
> So I am guessing that (3) is the old profile I used before.
> 
> I rebooted to cs 11785 + AMD patches, and retried (3) and it 
> works basically  the same as it did for 11408 (whew).  I 
> still haven't verified that the xen and kernel guest samples 
> are correct, but at least there are xen, kernel guest, kernel 
> user samples and I'm not getting any with (1) or (2).
> 
> So I am thinking that the problems I am seeing are related to 
> 64-bit hypervisor and the more recent fixes than Rosimildo's patchset.
> 
> --
> Best Regards,
> 
> Ray
> 
> Ray Bryant, Ph. D.
> x50038 or  512-602-0038
> AMD Performance Labs
> Austin, Texas
> 
> 
> 

Re: [XENOPROLIFE] New oprofile patch for XenOProfile

[Ray Bryant]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Wednesday 08 November 2006 16:06, Santos, Jose Renato G wrote:
>  Ray,
>
>  Do you get versions 1 and 2 working with 32bit Xen?
>  Could you please send me Rosimildo patches. I don't think I have it and
> I would like to compare with the others.
>  Thanks
>
>   Renato
>
<snip>

I'm attaching the patches I applied to make what I was referring to as "old 
profile".    

At the moment, I'm not setup to do a 32-bit hypervisor build or test (I short- 
sightedly decided some time ago just to work on 64-bit hypervisors and am 
still suffereing the effects of that decision.  :-) ).

I'll see if I can get access to a 32-bit built setup from Tom et al and try 
xenoprof for that case.

Please note, even Rosamildo would call the 3rd patch of this set a hack. :-)
Obviously, I had to revert this in order to get guest kernel profiling to work 
for the 32-bit guest/64-bit hypervisor case.

-- 
Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)

[-- Attachment #2: patches.for.renato.tar --]
[-- Type: application/x-tar, Size: 30720 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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