Skip to contentSkip to conversation

xen/x86: Add Xenoprofile support for AMD Family 17h

PATCH In review Gary R Hook 3 participants 7 messages May 23, 2017 – May 24, 2017

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 xen/x86: Add Xenoprofile support for AMD Family 17h

---
 xen/arch/x86/oprofile/nmi_int.c |    4 ++++
 1 file changed, 4 insertions(+)
xen/arch/x86/oprofile/nmi_int.c +4 -0
index 13534d491405..5ad48c12e515 100644
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
 				model = &op_athlon_spec;
 				cpu_type = "x86-64/family16h";
 				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
+				break;
 			}
 			break;
 

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#1 lore raw
Quoted 10 lines · Gary R Hook
---
 xen/arch/x86/oprofile/nmi_int.c |    4 ++++
 1 file changed, 4 insertions(+)
xen/arch/x86/oprofile/nmi_int.c +0 -0
index 13534d491405..5ad48c12e515 100644

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 9 lines
xen/arch/x86/oprofile/nmi_int.c +4 -0
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
 				model = &op_athlon_spec;
 				cpu_type = "x86-64/family16h";
 				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
+				break;
 			}
 			break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

-boris

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#2 lore raw
Quoted 17 lines · Boris Ostrovsky
Quoted 16 lines · Gary R Hook
---
  xen/arch/x86/oprofile/nmi_int.c |    4 ++++
  1 file changed, 4 insertions(+)
xen/arch/x86/oprofile/nmi_int.c +3 -0
index 13534d491405..5ad48c12e515 100644
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
  				model = &op_athlon_spec;
  				cpu_type = "x86-64/family16h";
  				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
Quoted 8 lines

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 3 lines
xen/arch/x86/oprofile/nmi_int.c +1 -0
+				break;
  			}
  			break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-)

I don't know whether the code is relevant (and if not, it should be removed, right?) but I don't like complaints, no matter how spurious. Thus, I minor patch.

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#3 lore raw
Quoted 28 lines · Gary R Hook
Quoted 18 lines · Boris Ostrovsky
Quoted 17 lines · Gary R Hook
---
  xen/arch/x86/oprofile/nmi_int.c |    4 ++++
  1 file changed, 4 insertions(+)
xen/arch/x86/oprofile/nmi_int.c +3 -0
index 13534d491405..5ad48c12e515 100644
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
                  model = &op_athlon_spec;
                  cpu_type = "x86-64/family16h";
                  break;
+            case 0x17:
+                                model = &op_amd_fam15h_spec;
+                cpu_type = "x86-64/family17h";
Quoted 8 lines

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 3 lines
xen/arch/x86/oprofile/nmi_int.c +1 -0
+                break;
              }
              break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

Quoted 6 lines

Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-)

I don't know whether the code is relevant (and if not, it should be removed, right?) but I don't like complaints, no matter how spurious. Thus, I minor patch.

FWIW, it looks like last meaningful patch to Linux oprofile code (baremetal) was around 2015.

-boris

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#4 lore raw
In reply to Gary R Hook
Quoted 29 lines
Quoted 1 line
Quoted 1 line · On 23.05.17 at 23:51, <[email protected]> wrote:
Quoted 7 lines · Boris Ostrovsky

Review

Quoted 6 lines · Gary R Hook
---
  xen/arch/x86/oprofile/nmi_int.c |    4 ++++
  1 file changed, 4 insertions(+)
(quoted diff) +0 -0

b/xen/arch/x86/oprofile/nmi_int.c

Quoted 10 lines
Quoted 10 lines

index 13534d491405..5ad48c12e515 100644

xen/arch/x86/oprofile/nmi_int.c +3 -0
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
  				model = &op_athlon_spec;
  				cpu_type = "x86-64/family16h";
  				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
Quoted 8 lines

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 3 lines
xen/arch/x86/oprofile/nmi_int.c +1 -0
+				break;
  			}
  			break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

Quoted 2 lines

Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-)

I think Boris meant more than just boot a system, i.e. whether you've actually used oprofile successfully with the change. Dealing with the "Initialization failed" message would not necessarily require properly installing handlers - we could also declare newer families unsupported and simply suppress the message in such cases. Note how on most Intel family 6 models code behaves in this very way.

Btw, please also note the indentation issue your patch has (spaces vs tabs).

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#5 lore raw
Quoted 29 lines · Jan Beulich
Quoted 29 lines
Quoted 1 line
Quoted 1 line · On 23.05.17 at 23:51, <[email protected]> wrote:
Quoted 7 lines · Boris Ostrovsky

Review

Quoted 6 lines · Gary R Hook
---
   xen/arch/x86/oprofile/nmi_int.c |    4 ++++
   1 file changed, 4 insertions(+)
(quoted diff) +0 -0

b/xen/arch/x86/oprofile/nmi_int.c

Quoted 18 lines

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 13 lines

index 13534d491405..5ad48c12e515 100644

xen/arch/x86/oprofile/nmi_int.c +4 -0
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
   				model = &op_athlon_spec;
   				cpu_type = "x86-64/family16h";
   				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
+				break;
   			}
   			break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

Quoted 5 lines
Quoted 2 lines

Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-)

I think Boris meant more than just boot a system, i.e. whether you've actually used oprofile successfully with the change.

My interpretation of the state of oprofile is that it's stagnant. Fron
what I can tell, the future is 'perf'. I looked around, but could find nothing current for a project. Where does that leave us?

Quoted 5 lines

Dealing with the
"Initialization failed" message would not necessarily require properly installing handlers - we could also declare newer families unsupported and simply suppress the message in such cases. Note how on most Intel family 6 models code behaves in this very way.

That would be even better, IMHO. What would we like to do?

Quoted 2 lines

Btw, please also note the indentation issue your patch has (spaces vs tabs).

I copied a line from above, which uses spaces. My bad, but the badly formatted code has been there for a while.

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

#6 lore raw
Quoted 34 lines
Quoted 1 line
Quoted 1 line · On 24.05.17 at 17:00, <[email protected]> wrote:
Quoted 32 lines · Jan Beulich
Quoted 31 lines
Quoted 1 line
Quoted 1 line · On 23.05.17 at 23:51, <[email protected]> wrote:
Quoted 7 lines · Boris Ostrovsky

Review

Quoted 6 lines · Gary R Hook
---
   xen/arch/x86/oprofile/nmi_int.c |    4 ++++
   1 file changed, 4 insertions(+)
(quoted diff) +0 -0

b/xen/arch/x86/oprofile/nmi_int.c

Quoted 10 lines
Quoted 10 lines

index 13534d491405..5ad48c12e515 100644

xen/arch/x86/oprofile/nmi_int.c +3 -0
@@ -419,6 +419,10 @@ static int __init nmi_init(void)
   				model = &op_athlon_spec;
   				cpu_type = "x86-64/family16h";
   				break;
+			case 0x17:
+                                model = &op_amd_fam15h_spec;
+				cpu_type = "x86-64/family17h";
Quoted 8 lines

xen/arch/x86/oprofile/nmi_int.c static int __init nmi_init(void) · line 427

Quoted 3 lines
xen/arch/x86/oprofile/nmi_int.c +1 -0
+				break;
   			}
   			break;

Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old.

Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-)

Quoted 6 lines
Quoted 2 lines

I think Boris meant more than just boot a system, i.e. whether you've actually used oprofile successfully with the change.

My interpretation of the state of oprofile is that it's stagnant. Fron what I can tell, the future is 'perf'. I looked around, but could find nothing current for a project. Where does that leave us?

Well, in that case you should at the very least clearly state that you did not actually test this.

Quoted 7 lines
Quoted 5 lines

Dealing with the
"Initialization failed" message would not necessarily require properly installing handlers - we could also declare newer families unsupported and simply suppress the message in such cases. Note how on most Intel family 6 models code behaves in this very way.

That would be even better, IMHO. What would we like to do?

Short of verifying whether things actually work with the change, my preference would be to leave the code alone. What's wrong with it saying it doesn't support the family in question? Second best option is to silence it as suggested.

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel