[5/5] xenperf: name "newer" hypercalls

Commit Message

Jan Beulich Dec. 3, 2021, 12:07 p.m. UTC

This table must not have got updated in quite a while; tmem_op for
example has managed to not only appear since then, but also disappear
again (adding a name for it nevertheless, to make more obvious that
something strange is going on if the slot would ever have a non-zero
value).

Signed-off-by: Jan Beulich <[e-mail]>
---
I wasn't really sure about x86's real names for arch_0 and arch_1. The
tool runs on the same host as the hypervisor, so __i386__ / __x86_64__
conditionals wouldn't be inappropriate to use ...

Comments

Andrew Cooper Dec. 17, 2021, 3:07 p.m. UTC | #1

On 03/12/2021 12:07, Jan Beulich wrote:
> This table must not have got updated in quite a while; tmem_op for
> example has managed to not only appear since then, but also disappear
> again (adding a name for it nevertheless, to make more obvious that
> something strange is going on if the slot would ever have a non-zero
> value).
>
> Signed-off-by: Jan Beulich <[e-mail]>
> ---
> I wasn't really sure about x86's real names for arch_0 and arch_1. The
> tool runs on the same host as the hypervisor, so __i386__ / __x86_64__
> conditionals wouldn't be inappropriate to use ...

This is a developer tool.  Noone is going to have a perfcounter enabled
hypervisor in production.

Therefore, I think the ifdef's will be fine.

Preferably with, but either way, Acked-by: Andrew Cooper
<[e-mail]>

Patch

--- a/tools/misc/xenperf.c
+++ b/tools/misc/xenperf.c
@@ -18,7 +18,7 @@ 
 #include <string.h>
 
 #define X(name) [__HYPERVISOR_##name] = #name
-const char *hypercall_name_table[64] =
+static const char *const hypercall_name_table[64] =
 {
     X(set_trap_table),
     X(mmu_update),
@@ -57,6 +57,11 @@  const char *hypercall_name_table[64] =
     X(sysctl),
     X(domctl),
     X(kexec_op),
+    X(tmem_op),
+    X(argo_op),
+    X(xenpmu_op),
+    X(dm_op),
+    X(hypfs_op),
     X(arch_0),
     X(arch_1),
     X(arch_2),