On Tue, 2015-05-12 at 21:34 +0530, Hemant Kumar wrote:
Hi Scott,My concern is seeing a generically named "kvm_perf.h" include a file
On 05/12/2015 03:38 AM, Scott Wood wrote:
On Fri, 2015-05-08 at 06:37 +0530, Hemant Kumar wrote:Are you suggesting to name it to something like _ASM_POWERPC_BOOK3S_PERF_H ?
diff --git a/arch/powerpc/include/uapi/asm/kvm_perf.h b/arch/powerpc/include/uapi/asm/kvm_perf.hPlease make sure that anything book3s-specific is named that way.
new file mode 100644
index 0000000..30fa670
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/kvm_perf.h
@@ -0,0 +1,15 @@
+#ifndef _ASM_POWERPC_KVM_PERF_H
+#define _ASM_POWERPC_KVM_PERF_H
+
+#include <asm/trace_book3s.h>
+#include <asm/kvm.h>
+
+#define DECODE_STR_LEN 20
+
+#define VCPU_ID "vcpu_id"
+
+#define KVM_ENTRY_TRACE "kvm_hv:kvm_guest_enter"
+#define KVM_EXIT_TRACE "kvm_hv:kvm_guest_exit"
+#define KVM_EXIT_REASON "trap"
+
+#endif /* _ASM_POWERPC_KVM_PERF_H */
called "trace_book3s.h" which defines "kvm_trace_symbol_hcall" with
presumably book3s-specific content, as well as wondering how much of the
rest of the file would be applicable if booke PPC were to implement perf
kvm.
I don't know enough about perf kvm to answer that question, but I've
seen enough cases of book3s or pseries specific code that was apparently
written with the belief that no other ppc64 implementations exist, or
that no other ppc implementations would want to implement a certain
feature, to be suspicous. Usually such cases can be dealt with after
the fact (albeit not as easily as if things were organized/namespaced
properly from the beginning), but this is uapi...
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@xxxxxxxxxxxxxxxx
https://lists.ozlabs.org/listinfo/linuxppc-dev