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 <jbeulich@suse.com>
---
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 ...

--- 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),

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 <jbeulich@suse.com>
> ---
> 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
<andrew.cooper3@citrix.com>