[PATCH 0/3] kvmtool: fixes for PowerPC

[PATCH 0/3] kvmtool: fixes for PowerPC

[Andre Przywara]

Hello,

some patches to fix at least the build of the new kvmtool for
PowerPC. I could only compile test it so far, so I'd be grateful
if people more familiar with that architecture can have a look
and maybe even test it on actual machines.

Cheers,
Andre.

Andre Przywara (3):
  powerpc: implement barrier primitives
  powerpc: use default endianness for converting guest/init
  powerpc: add hvcall.h header from Linux

 Makefile                      |   1 -
 powerpc/include/asm/hvcall.h  | 287 ++++++++++++++++++++++++++++++++++++++++++
 powerpc/include/kvm/barrier.h |   4 +-
 powerpc/spapr.h               |   3 -
 4 files changed, 290 insertions(+), 5 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

-- 
2.3.5

[PATCH 0/3] kvmtool: fixes for PowerPC

[Andre Przywara]

Hello,

some patches to fix at least the build of the new kvmtool for
PowerPC. I could only compile test it so far, so I'd be grateful
if people more familiar with that architecture can have a look
and maybe even test it on actual machines.

Cheers,
Andre.

Andre Przywara (3):
  powerpc: implement barrier primitives
  powerpc: use default endianness for converting guest/init
  powerpc: add hvcall.h header from Linux

 Makefile                      |   1 -
 powerpc/include/asm/hvcall.h  | 287 ++++++++++++++++++++++++++++++++++++++++++
 powerpc/include/kvm/barrier.h |   4 +-
 powerpc/spapr.h               |   3 -
 4 files changed, 290 insertions(+), 5 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

-- 
2.3.5

[PATCH 1/3] powerpc: implement barrier primitives

[Andre Przywara]

Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for powerpc.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

I just took what kvmtool seems to have used before, I actually have
no idea if "sync" is the right instruction or "lwsync" would do.
Would be nice if some people with PowerPC knowledge could comment.

Cheers,
Andre.

 powerpc/include/kvm/barrier.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/powerpc/include/kvm/barrier.h b/powerpc/include/kvm/barrier.h
index dd5115a..4b708ae 100644
--- a/powerpc/include/kvm/barrier.h
+++ b/powerpc/include/kvm/barrier.h
@@ -1,6 +1,8 @@
 #ifndef _KVM_BARRIER_H_
 #define _KVM_BARRIER_H_
 
-#include <asm/barrier.h>
+#define mb()   asm volatile ("sync" : : : "memory")
+#define rmb()  asm volatile ("sync" : : : "memory")
+#define wmb()  asm volatile ("sync" : : : "memory")
 
 #endif /* _KVM_BARRIER_H_ */
-- 
2.3.5

[PATCH 1/3] powerpc: implement barrier primitives

[Andre Przywara]

Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for powerpc.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

I just took what kvmtool seems to have used before, I actually have
no idea if "sync" is the right instruction or "lwsync" would do.
Would be nice if some people with PowerPC knowledge could comment.

Cheers,
Andre.

 powerpc/include/kvm/barrier.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/powerpc/include/kvm/barrier.h b/powerpc/include/kvm/barrier.h
index dd5115a..4b708ae 100644
--- a/powerpc/include/kvm/barrier.h
+++ b/powerpc/include/kvm/barrier.h
@@ -1,6 +1,8 @@
 #ifndef _KVM_BARRIER_H_
 #define _KVM_BARRIER_H_
 
-#include <asm/barrier.h>
+#define mb()   asm volatile ("sync" : : : "memory")
+#define rmb()  asm volatile ("sync" : : : "memory")
+#define wmb()  asm volatile ("sync" : : : "memory")
 
 #endif /* _KVM_BARRIER_H_ */
-- 
2.3.5

[PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian explicitly
when compiling kvmtool for powerpc.
This breaks if the compiler is actually targetting little endian
(which is true for the Debian port, for instance).
Remove the explicit big endianness switch from the linker call to
allow linking on little endian PowerPC builds again.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

this fixed the powerpc64le build for me, while still compiling fine
for big endian. Admittedly this whole init->guest_init.o conversion
has its issues (with MIPS, for instance), which deserve proper fixing,
but lets just fix that build for now.

Andre.

 Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6110b8e..c118e1a 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,6 @@ ifeq ($(ARCH), powerpc)
 	OBJS	+= powerpc/xics.o
 	ARCH_INCLUDE := powerpc/include
 	CFLAGS 	+= -m64
-	LDFLAGS += -m elf64ppc
 
 	ARCH_WANT_LIBFDT := y
 endif
-- 
2.3.5

[PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian explicitly
when compiling kvmtool for powerpc.
This breaks if the compiler is actually targetting little endian
(which is true for the Debian port, for instance).
Remove the explicit big endianness switch from the linker call to
allow linking on little endian PowerPC builds again.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

this fixed the powerpc64le build for me, while still compiling fine
for big endian. Admittedly this whole init->guest_init.o conversion
has its issues (with MIPS, for instance), which deserve proper fixing,
but lets just fix that build for now.

Andre.

 Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6110b8e..c118e1a 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,6 @@ ifeq ($(ARCH), powerpc)
 	OBJS	+= powerpc/xics.o
 	ARCH_INCLUDE := powerpc/include
 	CFLAGS 	+= -m64
-	LDFLAGS += -m elf64ppc
 
 	ARCH_WANT_LIBFDT := y
 endif
-- 
2.3.5

[PATCH 3/3] powerpc: add hvcall.h header from Linux

[Andre Przywara]

The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this header file directly.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

I copied most of the Linux header, without removing
definitions that kvmtool doesn't use. That should make updates
easier. If people would prefer a bespoke header, let me know.

Andre.

 powerpc/include/asm/hvcall.h | 287 +++++++++++++++++++++++++++++++++++++++++++
 powerpc/spapr.h              |   3 -
 2 files changed, 287 insertions(+), 3 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

diff --git a/powerpc/include/asm/hvcall.h b/powerpc/include/asm/hvcall.h
new file mode 100644
index 0000000..b6dc250
--- /dev/null
+++ b/powerpc/include/asm/hvcall.h
@@ -0,0 +1,287 @@
+#ifndef _ASM_POWERPC_HVCALL_H
+#define _ASM_POWERPC_HVCALL_H
+
+#define HVSC			.long 0x44000022
+
+#define H_SUCCESS	0
+#define H_BUSY		1	/* Hardware busy -- retry later */
+#define H_CLOSED	2	/* Resource closed */
+#define H_NOT_AVAILABLE 3
+#define H_CONSTRAINED	4	/* Resource request constrained to max allowed */
+#define H_PARTIAL       5
+#define H_IN_PROGRESS	14	/* Kind of like busy */
+#define H_PAGE_REGISTERED 15
+#define H_PARTIAL_STORE   16
+#define H_PENDING	17	/* returned from H_POLL_PENDING */
+#define H_CONTINUE	18	/* Returned from H_Join on success */
+#define H_LONG_BUSY_START_RANGE		9900  /* Start of long busy range */
+#define H_LONG_BUSY_ORDER_1_MSEC	9900  /* Long busy, hint that 1msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_MSEC	9901  /* Long busy, hint that 10msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_MSEC 	9902  /* Long busy, hint that 100msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_1_SEC		9903  /* Long busy, hint that 1sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_SEC	9904  /* Long busy, hint that 10sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_SEC	9905  /* Long busy, hint that 100sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_END_RANGE		9905  /* End of long busy range */
+
+/* Internal value used in book3s_hv kvm support; not returned to guests */
+#define H_TOO_HARD	9999
+
+#define H_HARDWARE	-1	/* Hardware error */
+#define H_FUNCTION	-2	/* Function not supported */
+#define H_PRIVILEGE	-3	/* Caller not privileged */
+#define H_PARAMETER	-4	/* Parameter invalid, out-of-range or conflicting */
+#define H_BAD_MODE	-5	/* Illegal msr value */
+#define H_PTEG_FULL	-6	/* PTEG is full */
+#define H_NOT_FOUND	-7	/* PTE was not found" */
+#define H_RESERVED_DABR	-8	/* DABR address is reserved by the hypervisor on this processor" */
+#define H_NO_MEM	-9
+#define H_AUTHORITY	-10
+#define H_PERMISSION	-11
+#define H_DROPPED	-12
+#define H_SOURCE_PARM	-13
+#define H_DEST_PARM	-14
+#define H_REMOTE_PARM	-15
+#define H_RESOURCE	-16
+#define H_ADAPTER_PARM  -17
+#define H_RH_PARM       -18
+#define H_RCQ_PARM      -19
+#define H_SCQ_PARM      -20
+#define H_EQ_PARM       -21
+#define H_RT_PARM       -22
+#define H_ST_PARM       -23
+#define H_SIGT_PARM     -24
+#define H_TOKEN_PARM    -25
+#define H_MLENGTH_PARM  -27
+#define H_MEM_PARM      -28
+#define H_MEM_ACCESS_PARM -29
+#define H_ATTR_PARM     -30
+#define H_PORT_PARM     -31
+#define H_MCG_PARM      -32
+#define H_VL_PARM       -33
+#define H_TSIZE_PARM    -34
+#define H_TRACE_PARM    -35
+
+#define H_MASK_PARM     -37
+#define H_MCG_FULL      -38
+#define H_ALIAS_EXIST   -39
+#define H_P_COUNTER     -40
+#define H_TABLE_FULL    -41
+#define H_ALT_TABLE     -42
+#define H_MR_CONDITION  -43
+#define H_NOT_ENOUGH_RESOURCES -44
+#define H_R_STATE       -45
+#define H_RESCINDED     -46
+#define H_P2		-55
+#define H_P3		-56
+#define H_P4		-57
+#define H_P5		-58
+#define H_P6		-59
+#define H_P7		-60
+#define H_P8		-61
+#define H_P9		-62
+#define H_TOO_BIG	-64
+#define H_OVERLAP	-68
+#define H_INTERRUPT	-69
+#define H_BAD_DATA	-70
+#define H_NOT_ACTIVE	-71
+#define H_SG_LIST	-72
+#define H_OP_MODE	-73
+#define H_COP_HW	-74
+#define H_UNSUPPORTED_FLAG_START	-256
+#define H_UNSUPPORTED_FLAG_END		-511
+#define H_MULTI_THREADS_ACTIVE	-9005
+#define H_OUTSTANDING_COP_OPS	-9006
+
+
+/* Long Busy is a condition that can be returned by the firmware
+ * when a call cannot be completed now, but the identical call
+ * should be retried later.  This prevents calls blocking in the
+ * firmware for long periods of time.  Annoyingly the firmware can return
+ * a range of return codes, hinting at how long we should wait before
+ * retrying.  If you don't care for the hint, the macro below is a good
+ * way to check for the long_busy return codes
+ */
+#define H_IS_LONG_BUSY(x)  ((x >= H_LONG_BUSY_START_RANGE) \
+			     && (x <= H_LONG_BUSY_END_RANGE))
+
+/* Flags */
+#define H_LARGE_PAGE		(1UL<<(63-16))
+#define H_EXACT			(1UL<<(63-24))	/* Use exact PTE or return H_PTEG_FULL */
+#define H_R_XLATE		(1UL<<(63-25))	/* include a valid logical page num in the pte if the valid bit is set */
+#define H_READ_4		(1UL<<(63-26))	/* Return 4 PTEs */
+#define H_PAGE_STATE_CHANGE	(1UL<<(63-28))
+#define H_PAGE_UNUSED		((1UL<<(63-29)) | (1UL<<(63-30)))
+#define H_PAGE_SET_UNUSED	(H_PAGE_STATE_CHANGE | H_PAGE_UNUSED)
+#define H_PAGE_SET_LOANED	(H_PAGE_SET_UNUSED | (1UL<<(63-31)))
+#define H_PAGE_SET_ACTIVE	H_PAGE_STATE_CHANGE
+#define H_AVPN			(1UL<<(63-32))	/* An avpn is provided as a sanity test */
+#define H_ANDCOND		(1UL<<(63-33))
+#define H_LOCAL			(1UL<<(63-35))
+#define H_ICACHE_INVALIDATE	(1UL<<(63-40))	/* icbi, etc.  (ignored for IO pages) */
+#define H_ICACHE_SYNCHRONIZE	(1UL<<(63-41))	/* dcbst, icbi, etc (ignored for IO pages */
+#define H_COALESCE_CAND	(1UL<<(63-42))	/* page is a good candidate for coalescing */
+#define H_ZERO_PAGE		(1UL<<(63-48))	/* zero the page before mapping (ignored for IO pages) */
+#define H_COPY_PAGE		(1UL<<(63-49))
+#define H_N			(1UL<<(63-61))
+#define H_PP1			(1UL<<(63-62))
+#define H_PP2			(1UL<<(63-63))
+
+/* Flags for H_REGISTER_VPA subfunction field */
+#define H_VPA_FUNC_SHIFT	(63-18)	/* Bit posn of subfunction code */
+#define H_VPA_FUNC_MASK		7UL
+#define H_VPA_REG_VPA		1UL	/* Register Virtual Processor Area */
+#define H_VPA_REG_DTL		2UL	/* Register Dispatch Trace Log */
+#define H_VPA_REG_SLB		3UL	/* Register SLB shadow buffer */
+#define H_VPA_DEREG_VPA		5UL	/* Deregister Virtual Processor Area */
+#define H_VPA_DEREG_DTL		6UL	/* Deregister Dispatch Trace Log */
+#define H_VPA_DEREG_SLB		7UL	/* Deregister SLB shadow buffer */
+
+/* VASI States */
+#define H_VASI_INVALID          0
+#define H_VASI_ENABLED          1
+#define H_VASI_ABORTED          2
+#define H_VASI_SUSPENDING       3
+#define H_VASI_SUSPENDED        4
+#define H_VASI_RESUMED          5
+#define H_VASI_COMPLETED        6
+
+/* Each control block has to be on a 4K boundary */
+#define H_CB_ALIGNMENT          4096
+
+/* pSeries hypervisor opcodes */
+#define H_REMOVE		0x04
+#define H_ENTER			0x08
+#define H_READ			0x0c
+#define H_CLEAR_MOD		0x10
+#define H_CLEAR_REF		0x14
+#define H_PROTECT		0x18
+#define H_GET_TCE		0x1c
+#define H_PUT_TCE		0x20
+#define H_SET_SPRG0		0x24
+#define H_SET_DABR		0x28
+#define H_PAGE_INIT		0x2c
+#define H_SET_ASR		0x30
+#define H_ASR_ON		0x34
+#define H_ASR_OFF		0x38
+#define H_LOGICAL_CI_LOAD	0x3c
+#define H_LOGICAL_CI_STORE	0x40
+#define H_LOGICAL_CACHE_LOAD	0x44
+#define H_LOGICAL_CACHE_STORE	0x48
+#define H_LOGICAL_ICBI		0x4c
+#define H_LOGICAL_DCBF		0x50
+#define H_GET_TERM_CHAR		0x54
+#define H_PUT_TERM_CHAR		0x58
+#define H_REAL_TO_LOGICAL	0x5c
+#define H_HYPERVISOR_DATA	0x60
+#define H_EOI			0x64
+#define H_CPPR			0x68
+#define H_IPI			0x6c
+#define H_IPOLL			0x70
+#define H_XIRR			0x74
+#define H_PERFMON		0x7c
+#define H_MIGRATE_DMA		0x78
+#define H_REGISTER_VPA		0xDC
+#define H_CEDE			0xE0
+#define H_CONFER		0xE4
+#define H_PROD			0xE8
+#define H_GET_PPP		0xEC
+#define H_SET_PPP		0xF0
+#define H_PURR			0xF4
+#define H_PIC			0xF8
+#define H_REG_CRQ		0xFC
+#define H_FREE_CRQ		0x100
+#define H_VIO_SIGNAL		0x104
+#define H_SEND_CRQ		0x108
+#define H_COPY_RDMA		0x110
+#define H_REGISTER_LOGICAL_LAN	0x114
+#define H_FREE_LOGICAL_LAN	0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN	0x120
+#define H_BULK_REMOVE		0x124
+#define H_MULTICAST_CTRL	0x130
+#define H_SET_XDABR		0x134
+#define H_STUFF_TCE		0x138
+#define H_PUT_TCE_INDIRECT	0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
+#define H_VTERM_PARTNER_INFO	0x150
+#define H_REGISTER_VTERM	0x154
+#define H_FREE_VTERM		0x158
+#define H_RESET_EVENTS          0x15C
+#define H_ALLOC_RESOURCE        0x160
+#define H_FREE_RESOURCE         0x164
+#define H_MODIFY_QP             0x168
+#define H_QUERY_QP              0x16C
+#define H_REREGISTER_PMR        0x170
+#define H_REGISTER_SMR          0x174
+#define H_QUERY_MR              0x178
+#define H_QUERY_MW              0x17C
+#define H_QUERY_HCA             0x180
+#define H_QUERY_PORT            0x184
+#define H_MODIFY_PORT           0x188
+#define H_DEFINE_AQP1           0x18C
+#define H_GET_TRACE_BUFFER      0x190
+#define H_DEFINE_AQP0           0x194
+#define H_RESIZE_MR             0x198
+#define H_ATTACH_MCQP           0x19C
+#define H_DETACH_MCQP           0x1A0
+#define H_CREATE_RPT            0x1A4
+#define H_REMOVE_RPT            0x1A8
+#define H_REGISTER_RPAGES       0x1AC
+#define H_DISABLE_AND_GETC      0x1B0
+#define H_ERROR_DATA            0x1B4
+#define H_GET_HCA_INFO          0x1B8
+#define H_GET_PERF_COUNT        0x1BC
+#define H_MANAGE_TRACE          0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
+#define H_QUERY_INT_STATE       0x1E4
+#define H_POLL_PENDING		0x1D8
+#define H_ILLAN_ATTRIBUTES	0x244
+#define H_MODIFY_HEA_QP		0x250
+#define H_QUERY_HEA_QP		0x254
+#define H_QUERY_HEA		0x258
+#define H_QUERY_HEA_PORT	0x25C
+#define H_MODIFY_HEA_PORT	0x260
+#define H_REG_BCMC		0x264
+#define H_DEREG_BCMC		0x268
+#define H_REGISTER_HEA_RPAGES	0x26C
+#define H_DISABLE_AND_GET_HEA	0x270
+#define H_GET_HEA_INFO		0x274
+#define H_ALLOC_HEA_RESOURCE	0x278
+#define H_ADD_CONN		0x284
+#define H_DEL_CONN		0x288
+#define H_JOIN			0x298
+#define H_VASI_STATE            0x2A4
+#define H_ENABLE_CRQ		0x2B0
+#define H_GET_EM_PARMS		0x2B8
+#define H_SET_MPP		0x2D0
+#define H_GET_MPP		0x2D4
+#define H_HOME_NODE_ASSOCIATIVITY 0x2EC
+#define H_BEST_ENERGY		0x2F4
+#define H_XIRR_X		0x2FC
+#define H_RANDOM		0x300
+#define H_COP			0x304
+#define H_GET_MPP_X		0x314
+#define H_SET_MODE		0x31C
+#define MAX_HCALL_OPCODE	H_SET_MODE
+
+/* Platform specific hcalls, used by KVM */
+#define H_RTAS			0xf000
+
+/* "Platform specific hcalls", provided by PHYP */
+#define H_GET_24X7_CATALOG_PAGE	0xF078
+#define H_GET_24X7_DATA		0xF07C
+#define H_GET_PERF_COUNTER_INFO	0xF080
+
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR		1
+#define H_SET_MODE_RESOURCE_SET_DAWR		2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE	3
+#define H_SET_MODE_RESOURCE_LE			4
+
+#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/powerpc/spapr.h b/powerpc/spapr.h
index 0537f88..4c6e349 100644
--- a/powerpc/spapr.h
+++ b/powerpc/spapr.h
@@ -16,10 +16,7 @@
 
 #include <inttypes.h>
 
-/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
-#define __KERNEL__
 #include <asm/hvcall.h>
-#undef __KERNEL__
 
 #include "kvm/kvm.h"
 #include "kvm/kvm-cpu.h"
-- 
2.3.5

[PATCH 3/3] powerpc: add hvcall.h header from Linux

[Andre Przywara]

The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this header file directly.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

I copied most of the Linux header, without removing
definitions that kvmtool doesn't use. That should make updates
easier. If people would prefer a bespoke header, let me know.

Andre.

 powerpc/include/asm/hvcall.h | 287 +++++++++++++++++++++++++++++++++++++++++++
 powerpc/spapr.h              |   3 -
 2 files changed, 287 insertions(+), 3 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

diff --git a/powerpc/include/asm/hvcall.h b/powerpc/include/asm/hvcall.h
new file mode 100644
index 0000000..b6dc250
--- /dev/null
+++ b/powerpc/include/asm/hvcall.h
@@ -0,0 +1,287 @@
+#ifndef _ASM_POWERPC_HVCALL_H
+#define _ASM_POWERPC_HVCALL_H
+
+#define HVSC			.long 0x44000022
+
+#define H_SUCCESS	0
+#define H_BUSY		1	/* Hardware busy -- retry later */
+#define H_CLOSED	2	/* Resource closed */
+#define H_NOT_AVAILABLE 3
+#define H_CONSTRAINED	4	/* Resource request constrained to max allowed */
+#define H_PARTIAL       5
+#define H_IN_PROGRESS	14	/* Kind of like busy */
+#define H_PAGE_REGISTERED 15
+#define H_PARTIAL_STORE   16
+#define H_PENDING	17	/* returned from H_POLL_PENDING */
+#define H_CONTINUE	18	/* Returned from H_Join on success */
+#define H_LONG_BUSY_START_RANGE		9900  /* Start of long busy range */
+#define H_LONG_BUSY_ORDER_1_MSEC	9900  /* Long busy, hint that 1msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_MSEC	9901  /* Long busy, hint that 10msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_MSEC 	9902  /* Long busy, hint that 100msec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_1_SEC		9903  /* Long busy, hint that 1sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_SEC	9904  /* Long busy, hint that 10sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_SEC	9905  /* Long busy, hint that 100sec \
+						 is a good time to retry */
+#define H_LONG_BUSY_END_RANGE		9905  /* End of long busy range */
+
+/* Internal value used in book3s_hv kvm support; not returned to guests */
+#define H_TOO_HARD	9999
+
+#define H_HARDWARE	-1	/* Hardware error */
+#define H_FUNCTION	-2	/* Function not supported */
+#define H_PRIVILEGE	-3	/* Caller not privileged */
+#define H_PARAMETER	-4	/* Parameter invalid, out-of-range or conflicting */
+#define H_BAD_MODE	-5	/* Illegal msr value */
+#define H_PTEG_FULL	-6	/* PTEG is full */
+#define H_NOT_FOUND	-7	/* PTE was not found" */
+#define H_RESERVED_DABR	-8	/* DABR address is reserved by the hypervisor on this processor" */
+#define H_NO_MEM	-9
+#define H_AUTHORITY	-10
+#define H_PERMISSION	-11
+#define H_DROPPED	-12
+#define H_SOURCE_PARM	-13
+#define H_DEST_PARM	-14
+#define H_REMOTE_PARM	-15
+#define H_RESOURCE	-16
+#define H_ADAPTER_PARM  -17
+#define H_RH_PARM       -18
+#define H_RCQ_PARM      -19
+#define H_SCQ_PARM      -20
+#define H_EQ_PARM       -21
+#define H_RT_PARM       -22
+#define H_ST_PARM       -23
+#define H_SIGT_PARM     -24
+#define H_TOKEN_PARM    -25
+#define H_MLENGTH_PARM  -27
+#define H_MEM_PARM      -28
+#define H_MEM_ACCESS_PARM -29
+#define H_ATTR_PARM     -30
+#define H_PORT_PARM     -31
+#define H_MCG_PARM      -32
+#define H_VL_PARM       -33
+#define H_TSIZE_PARM    -34
+#define H_TRACE_PARM    -35
+
+#define H_MASK_PARM     -37
+#define H_MCG_FULL      -38
+#define H_ALIAS_EXIST   -39
+#define H_P_COUNTER     -40
+#define H_TABLE_FULL    -41
+#define H_ALT_TABLE     -42
+#define H_MR_CONDITION  -43
+#define H_NOT_ENOUGH_RESOURCES -44
+#define H_R_STATE       -45
+#define H_RESCINDED     -46
+#define H_P2		-55
+#define H_P3		-56
+#define H_P4		-57
+#define H_P5		-58
+#define H_P6		-59
+#define H_P7		-60
+#define H_P8		-61
+#define H_P9		-62
+#define H_TOO_BIG	-64
+#define H_OVERLAP	-68
+#define H_INTERRUPT	-69
+#define H_BAD_DATA	-70
+#define H_NOT_ACTIVE	-71
+#define H_SG_LIST	-72
+#define H_OP_MODE	-73
+#define H_COP_HW	-74
+#define H_UNSUPPORTED_FLAG_START	-256
+#define H_UNSUPPORTED_FLAG_END		-511
+#define H_MULTI_THREADS_ACTIVE	-9005
+#define H_OUTSTANDING_COP_OPS	-9006
+
+
+/* Long Busy is a condition that can be returned by the firmware
+ * when a call cannot be completed now, but the identical call
+ * should be retried later.  This prevents calls blocking in the
+ * firmware for long periods of time.  Annoyingly the firmware can return
+ * a range of return codes, hinting at how long we should wait before
+ * retrying.  If you don't care for the hint, the macro below is a good
+ * way to check for the long_busy return codes
+ */
+#define H_IS_LONG_BUSY(x)  ((x >= H_LONG_BUSY_START_RANGE) \
+			     && (x <= H_LONG_BUSY_END_RANGE))
+
+/* Flags */
+#define H_LARGE_PAGE		(1UL<<(63-16))
+#define H_EXACT			(1UL<<(63-24))	/* Use exact PTE or return H_PTEG_FULL */
+#define H_R_XLATE		(1UL<<(63-25))	/* include a valid logical page num in the pte if the valid bit is set */
+#define H_READ_4		(1UL<<(63-26))	/* Return 4 PTEs */
+#define H_PAGE_STATE_CHANGE	(1UL<<(63-28))
+#define H_PAGE_UNUSED		((1UL<<(63-29)) | (1UL<<(63-30)))
+#define H_PAGE_SET_UNUSED	(H_PAGE_STATE_CHANGE | H_PAGE_UNUSED)
+#define H_PAGE_SET_LOANED	(H_PAGE_SET_UNUSED | (1UL<<(63-31)))
+#define H_PAGE_SET_ACTIVE	H_PAGE_STATE_CHANGE
+#define H_AVPN			(1UL<<(63-32))	/* An avpn is provided as a sanity test */
+#define H_ANDCOND		(1UL<<(63-33))
+#define H_LOCAL			(1UL<<(63-35))
+#define H_ICACHE_INVALIDATE	(1UL<<(63-40))	/* icbi, etc.  (ignored for IO pages) */
+#define H_ICACHE_SYNCHRONIZE	(1UL<<(63-41))	/* dcbst, icbi, etc (ignored for IO pages */
+#define H_COALESCE_CAND	(1UL<<(63-42))	/* page is a good candidate for coalescing */
+#define H_ZERO_PAGE		(1UL<<(63-48))	/* zero the page before mapping (ignored for IO pages) */
+#define H_COPY_PAGE		(1UL<<(63-49))
+#define H_N			(1UL<<(63-61))
+#define H_PP1			(1UL<<(63-62))
+#define H_PP2			(1UL<<(63-63))
+
+/* Flags for H_REGISTER_VPA subfunction field */
+#define H_VPA_FUNC_SHIFT	(63-18)	/* Bit posn of subfunction code */
+#define H_VPA_FUNC_MASK		7UL
+#define H_VPA_REG_VPA		1UL	/* Register Virtual Processor Area */
+#define H_VPA_REG_DTL		2UL	/* Register Dispatch Trace Log */
+#define H_VPA_REG_SLB		3UL	/* Register SLB shadow buffer */
+#define H_VPA_DEREG_VPA		5UL	/* Deregister Virtual Processor Area */
+#define H_VPA_DEREG_DTL		6UL	/* Deregister Dispatch Trace Log */
+#define H_VPA_DEREG_SLB		7UL	/* Deregister SLB shadow buffer */
+
+/* VASI States */
+#define H_VASI_INVALID          0
+#define H_VASI_ENABLED          1
+#define H_VASI_ABORTED          2
+#define H_VASI_SUSPENDING       3
+#define H_VASI_SUSPENDED        4
+#define H_VASI_RESUMED          5
+#define H_VASI_COMPLETED        6
+
+/* Each control block has to be on a 4K boundary */
+#define H_CB_ALIGNMENT          4096
+
+/* pSeries hypervisor opcodes */
+#define H_REMOVE		0x04
+#define H_ENTER			0x08
+#define H_READ			0x0c
+#define H_CLEAR_MOD		0x10
+#define H_CLEAR_REF		0x14
+#define H_PROTECT		0x18
+#define H_GET_TCE		0x1c
+#define H_PUT_TCE		0x20
+#define H_SET_SPRG0		0x24
+#define H_SET_DABR		0x28
+#define H_PAGE_INIT		0x2c
+#define H_SET_ASR		0x30
+#define H_ASR_ON		0x34
+#define H_ASR_OFF		0x38
+#define H_LOGICAL_CI_LOAD	0x3c
+#define H_LOGICAL_CI_STORE	0x40
+#define H_LOGICAL_CACHE_LOAD	0x44
+#define H_LOGICAL_CACHE_STORE	0x48
+#define H_LOGICAL_ICBI		0x4c
+#define H_LOGICAL_DCBF		0x50
+#define H_GET_TERM_CHAR		0x54
+#define H_PUT_TERM_CHAR		0x58
+#define H_REAL_TO_LOGICAL	0x5c
+#define H_HYPERVISOR_DATA	0x60
+#define H_EOI			0x64
+#define H_CPPR			0x68
+#define H_IPI			0x6c
+#define H_IPOLL			0x70
+#define H_XIRR			0x74
+#define H_PERFMON		0x7c
+#define H_MIGRATE_DMA		0x78
+#define H_REGISTER_VPA		0xDC
+#define H_CEDE			0xE0
+#define H_CONFER		0xE4
+#define H_PROD			0xE8
+#define H_GET_PPP		0xEC
+#define H_SET_PPP		0xF0
+#define H_PURR			0xF4
+#define H_PIC			0xF8
+#define H_REG_CRQ		0xFC
+#define H_FREE_CRQ		0x100
+#define H_VIO_SIGNAL		0x104
+#define H_SEND_CRQ		0x108
+#define H_COPY_RDMA		0x110
+#define H_REGISTER_LOGICAL_LAN	0x114
+#define H_FREE_LOGICAL_LAN	0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN	0x120
+#define H_BULK_REMOVE		0x124
+#define H_MULTICAST_CTRL	0x130
+#define H_SET_XDABR		0x134
+#define H_STUFF_TCE		0x138
+#define H_PUT_TCE_INDIRECT	0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
+#define H_VTERM_PARTNER_INFO	0x150
+#define H_REGISTER_VTERM	0x154
+#define H_FREE_VTERM		0x158
+#define H_RESET_EVENTS          0x15C
+#define H_ALLOC_RESOURCE        0x160
+#define H_FREE_RESOURCE         0x164
+#define H_MODIFY_QP             0x168
+#define H_QUERY_QP              0x16C
+#define H_REREGISTER_PMR        0x170
+#define H_REGISTER_SMR          0x174
+#define H_QUERY_MR              0x178
+#define H_QUERY_MW              0x17C
+#define H_QUERY_HCA             0x180
+#define H_QUERY_PORT            0x184
+#define H_MODIFY_PORT           0x188
+#define H_DEFINE_AQP1           0x18C
+#define H_GET_TRACE_BUFFER      0x190
+#define H_DEFINE_AQP0           0x194
+#define H_RESIZE_MR             0x198
+#define H_ATTACH_MCQP           0x19C
+#define H_DETACH_MCQP           0x1A0
+#define H_CREATE_RPT            0x1A4
+#define H_REMOVE_RPT            0x1A8
+#define H_REGISTER_RPAGES       0x1AC
+#define H_DISABLE_AND_GETC      0x1B0
+#define H_ERROR_DATA            0x1B4
+#define H_GET_HCA_INFO          0x1B8
+#define H_GET_PERF_COUNT        0x1BC
+#define H_MANAGE_TRACE          0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
+#define H_QUERY_INT_STATE       0x1E4
+#define H_POLL_PENDING		0x1D8
+#define H_ILLAN_ATTRIBUTES	0x244
+#define H_MODIFY_HEA_QP		0x250
+#define H_QUERY_HEA_QP		0x254
+#define H_QUERY_HEA		0x258
+#define H_QUERY_HEA_PORT	0x25C
+#define H_MODIFY_HEA_PORT	0x260
+#define H_REG_BCMC		0x264
+#define H_DEREG_BCMC		0x268
+#define H_REGISTER_HEA_RPAGES	0x26C
+#define H_DISABLE_AND_GET_HEA	0x270
+#define H_GET_HEA_INFO		0x274
+#define H_ALLOC_HEA_RESOURCE	0x278
+#define H_ADD_CONN		0x284
+#define H_DEL_CONN		0x288
+#define H_JOIN			0x298
+#define H_VASI_STATE            0x2A4
+#define H_ENABLE_CRQ		0x2B0
+#define H_GET_EM_PARMS		0x2B8
+#define H_SET_MPP		0x2D0
+#define H_GET_MPP		0x2D4
+#define H_HOME_NODE_ASSOCIATIVITY 0x2EC
+#define H_BEST_ENERGY		0x2F4
+#define H_XIRR_X		0x2FC
+#define H_RANDOM		0x300
+#define H_COP			0x304
+#define H_GET_MPP_X		0x314
+#define H_SET_MODE		0x31C
+#define MAX_HCALL_OPCODE	H_SET_MODE
+
+/* Platform specific hcalls, used by KVM */
+#define H_RTAS			0xf000
+
+/* "Platform specific hcalls", provided by PHYP */
+#define H_GET_24X7_CATALOG_PAGE	0xF078
+#define H_GET_24X7_DATA		0xF07C
+#define H_GET_PERF_COUNTER_INFO	0xF080
+
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR		1
+#define H_SET_MODE_RESOURCE_SET_DAWR		2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE	3
+#define H_SET_MODE_RESOURCE_LE			4
+
+#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/powerpc/spapr.h b/powerpc/spapr.h
index 0537f88..4c6e349 100644
--- a/powerpc/spapr.h
+++ b/powerpc/spapr.h
@@ -16,10 +16,7 @@
 
 #include <inttypes.h>
 
-/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
-#define __KERNEL__
 #include <asm/hvcall.h>
-#undef __KERNEL__
 
 #include "kvm/kvm.h"
 #include "kvm/kvm-cpu.h"
-- 
2.3.5

Re: [PATCH 3/3] powerpc: add hvcall.h header from Linux

[Will Deacon]

On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
> The powerpc code uses some PAPR hypercalls, of which we need the
> hypercall number. Copy the macro definition parts from the kernel's
> (private) hvcall.h file and remove the extra tricks formerly used
> to be able to include this header file directly.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> I copied most of the Linux header, without removing
> definitions that kvmtool doesn't use. That should make updates
> easier. If people would prefer a bespoke header, let me know.

I'd rather just #define the stuff we need now that we're outside of the
kernel source tree.

Will

Re: [PATCH 3/3] powerpc: add hvcall.h header from Linux

[Will Deacon]

On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
> The powerpc code uses some PAPR hypercalls, of which we need the
> hypercall number. Copy the macro definition parts from the kernel's
> (private) hvcall.h file and remove the extra tricks formerly used
> to be able to include this header file directly.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> I copied most of the Linux header, without removing
> definitions that kvmtool doesn't use. That should make updates
> easier. If people would prefer a bespoke header, let me know.

I'd rather just #define the stuff we need now that we're outside of the
kernel source tree.

Will

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Will Deacon]

On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> Instead of referring to the Linux header including the barrier
> macros, copy over the rather simple implementation for the PowerPC
> barrier instructions kvmtool uses. This fixes build for powerpc.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> I just took what kvmtool seems to have used before, I actually have
> no idea if "sync" is the right instruction or "lwsync" would do.
> Would be nice if some people with PowerPC knowledge could comment.

I *think* we can use lwsync for rmb and wmb, but would want confirmation
from a ppc guy before making that change!

Will

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Will Deacon]

On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> Instead of referring to the Linux header including the barrier
> macros, copy over the rather simple implementation for the PowerPC
> barrier instructions kvmtool uses. This fixes build for powerpc.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> I just took what kvmtool seems to have used before, I actually have
> no idea if "sync" is the right instruction or "lwsync" would do.
> Would be nice if some people with PowerPC knowledge could comment.

I *think* we can use lwsync for rmb and wmb, but would want confirmation
from a ppc guy before making that change!

Will

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Alexander Graf]

On 17.06.15 12:15, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
>> Instead of referring to the Linux header including the barrier
>> macros, copy over the rather simple implementation for the PowerPC
>> barrier instructions kvmtool uses. This fixes build for powerpc.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Hi,
>>
>> I just took what kvmtool seems to have used before, I actually have
>> no idea if "sync" is the right instruction or "lwsync" would do.
>> Would be nice if some people with PowerPC knowledge could comment.
> 
> I *think* we can use lwsync for rmb and wmb, but would want confirmation
> from a ppc guy before making that change!

Also I'd prefer to play safe for now :)


Alex

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Alexander Graf]

On 17.06.15 12:15, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
>> Instead of referring to the Linux header including the barrier
>> macros, copy over the rather simple implementation for the PowerPC
>> barrier instructions kvmtool uses. This fixes build for powerpc.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Hi,
>>
>> I just took what kvmtool seems to have used before, I actually have
>> no idea if "sync" is the right instruction or "lwsync" would do.
>> Would be nice if some people with PowerPC knowledge could comment.
> 
> I *think* we can use lwsync for rmb and wmb, but would want confirmation
> from a ppc guy before making that change!

Also I'd prefer to play safe for now :)


Alex

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Michael Ellerman]

On Wed, 2015-06-17 at 11:15 +0100, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> > Instead of referring to the Linux header including the barrier
> > macros, copy over the rather simple implementation for the PowerPC
> > barrier instructions kvmtool uses. This fixes build for powerpc.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > I just took what kvmtool seems to have used before, I actually have
> > no idea if "sync" is the right instruction or "lwsync" would do.
> > Would be nice if some people with PowerPC knowledge could comment.
> 
> I *think* we can use lwsync for rmb and wmb, but would want confirmation
> from a ppc guy before making that change!

Ugh, memory barriers :)

You probably can use lwsync, assuming you're only ordering cacheable vs
cacheable.

But, lwsync has given us pain in the past[1], so I'd be happier if you just used
sync.

cheers

[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51d7d5205d3389a32859f9939f1093f267409929

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Michael Ellerman]

On Wed, 2015-06-17 at 11:15 +0100, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> > Instead of referring to the Linux header including the barrier
> > macros, copy over the rather simple implementation for the PowerPC
> > barrier instructions kvmtool uses. This fixes build for powerpc.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > I just took what kvmtool seems to have used before, I actually have
> > no idea if "sync" is the right instruction or "lwsync" would do.
> > Would be nice if some people with PowerPC knowledge could comment.
> 
> I *think* we can use lwsync for rmb and wmb, but would want confirmation
> from a ppc guy before making that change!

Ugh, memory barriers :)

You probably can use lwsync, assuming you're only ordering cacheable vs
cacheable.

But, lwsync has given us pain in the past[1], so I'd be happier if you just used
sync.

cheers

[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?idQd7d5205d3389a32859f9939f1093f267409929

Re: [PATCH 3/3] powerpc: add hvcall.h header from Linux

[Michael Ellerman]

On Wed, 2015-06-17 at 11:13 +0100, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
> > The powerpc code uses some PAPR hypercalls, of which we need the
> > hypercall number. Copy the macro definition parts from the kernel's
> > (private) hvcall.h file and remove the extra tricks formerly used
> > to be able to include this header file directly.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > I copied most of the Linux header, without removing
> > definitions that kvmtool doesn't use. That should make updates
> > easier. If people would prefer a bespoke header, let me know.
> 
> I'd rather just #define the stuff we need now that we're outside of the
> kernel source tree.

Yeah that's probably cleaner.

I think you only need:

  H_CPPR
  H_EOI
  H_FUNCTION
  H_GET_TERM_CHAR
  H_HARDWARE
  H_IPI
  H_LOGICAL_CACHE_LOAD
  H_LOGICAL_CACHE_STORE
  H_LOGICAL_CI_LOAD
  H_LOGICAL_CI_STORE
  H_LOGICAL_DCBF
  H_LOGICAL_ICBI
  H_PARAMETER
  H_PUT_TERM_CHAR
  H_SET_DABR
  H_SUCCESS
  H_XIRR
  KVMPPC_H_RTAS

cheers

Re: [PATCH 3/3] powerpc: add hvcall.h header from Linux

[Michael Ellerman]

On Wed, 2015-06-17 at 11:13 +0100, Will Deacon wrote:
> On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
> > The powerpc code uses some PAPR hypercalls, of which we need the
> > hypercall number. Copy the macro definition parts from the kernel's
> > (private) hvcall.h file and remove the extra tricks formerly used
> > to be able to include this header file directly.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > I copied most of the Linux header, without removing
> > definitions that kvmtool doesn't use. That should make updates
> > easier. If people would prefer a bespoke header, let me know.
> 
> I'd rather just #define the stuff we need now that we're outside of the
> kernel source tree.

Yeah that's probably cleaner.

I think you only need:

  H_CPPR
  H_EOI
  H_FUNCTION
  H_GET_TERM_CHAR
  H_HARDWARE
  H_IPI
  H_LOGICAL_CACHE_LOAD
  H_LOGICAL_CACHE_STORE
  H_LOGICAL_CI_LOAD
  H_LOGICAL_CI_STORE
  H_LOGICAL_DCBF
  H_LOGICAL_ICBI
  H_PARAMETER
  H_PUT_TERM_CHAR
  H_SET_DABR
  H_SUCCESS
  H_XIRR
  KVMPPC_H_RTAS

cheers

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Will Deacon]

On Thu, Jun 18, 2015 at 10:11:58AM +0100, Michael Ellerman wrote:
> On Wed, 2015-06-17 at 11:15 +0100, Will Deacon wrote:
> > On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> > > Instead of referring to the Linux header including the barrier
> > > macros, copy over the rather simple implementation for the PowerPC
> > > barrier instructions kvmtool uses. This fixes build for powerpc.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > > Hi,
> > > 
> > > I just took what kvmtool seems to have used before, I actually have
> > > no idea if "sync" is the right instruction or "lwsync" would do.
> > > Would be nice if some people with PowerPC knowledge could comment.
> > 
> > I *think* we can use lwsync for rmb and wmb, but would want confirmation
> > from a ppc guy before making that change!
> 
> Ugh, memory barriers :)

I prefer to call them "Job Security" :)

> You probably can use lwsync, assuming you're only ordering cacheable vs
> cacheable.
> 
> But, lwsync has given us pain in the past[1], so I'd be happier if you just used
> sync.

No probs. I pushed Andre's original patch.

Will

Re: [PATCH 1/3] powerpc: implement barrier primitives

[Will Deacon]

On Thu, Jun 18, 2015 at 10:11:58AM +0100, Michael Ellerman wrote:
> On Wed, 2015-06-17 at 11:15 +0100, Will Deacon wrote:
> > On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
> > > Instead of referring to the Linux header including the barrier
> > > macros, copy over the rather simple implementation for the PowerPC
> > > barrier instructions kvmtool uses. This fixes build for powerpc.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > > Hi,
> > > 
> > > I just took what kvmtool seems to have used before, I actually have
> > > no idea if "sync" is the right instruction or "lwsync" would do.
> > > Would be nice if some people with PowerPC knowledge could comment.
> > 
> > I *think* we can use lwsync for rmb and wmb, but would want confirmation
> > from a ppc guy before making that change!
> 
> Ugh, memory barriers :)

I prefer to call them "Job Security" :)

> You probably can use lwsync, assuming you're only ordering cacheable vs
> cacheable.
> 
> But, lwsync has given us pain in the past[1], so I'd be happier if you just used
> sync.

No probs. I pushed Andre's original patch.

Will

[PATCH v2] powerpc: add hvcall.h header from Linux

[Andre Przywara]

The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy just the needed macro definitions from the
kernel's (private) hvcall.h file and remove the extra tricks formerly
used to be able to include this header file directly.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

this version of the header file just contains the definitions we
need, while still being easily diff-able against the original file.
Please consider applying this one.

Cheers,
Andre.

 powerpc/include/asm/hvcall.h | 33 +++++++++++++++++++++++++++++++++
 powerpc/spapr.h              |  3 ---
 2 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

diff --git a/powerpc/include/asm/hvcall.h b/powerpc/include/asm/hvcall.h
new file mode 100644
index 0000000..9d58f9b
--- /dev/null
+++ b/powerpc/include/asm/hvcall.h
@@ -0,0 +1,33 @@
+#ifndef _ASM_POWERPC_HVCALL_H
+#define _ASM_POWERPC_HVCALL_H
+
+/* This file is a trimmed-down version of arch/powerpc/include/asm/hvcall.h. */
+
+#define H_SUCCESS	0
+
+#define H_HARDWARE	-1	/* Hardware error */
+#define H_FUNCTION	-2	/* Function not supported */
+#define H_PRIVILEGE	-3	/* Caller not privileged */
+#define H_PARAMETER	-4	/* Parameter invalid, out-of-range or conflicting */
+
+#define H_SET_DABR		0x28
+#define H_LOGICAL_CI_LOAD	0x3c
+#define H_LOGICAL_CI_STORE	0x40
+#define H_LOGICAL_CACHE_LOAD	0x44
+#define H_LOGICAL_CACHE_STORE	0x48
+#define H_LOGICAL_ICBI		0x4c
+#define H_LOGICAL_DCBF		0x50
+
+#define H_GET_TERM_CHAR		0x54
+#define H_PUT_TERM_CHAR		0x58
+
+#define H_EOI			0x64
+#define H_CPPR			0x68
+#define H_IPI			0x6c
+#define H_IPOLL			0x70
+#define H_XIRR			0x74
+
+#define H_SET_MODE		0x31C
+#define MAX_HCALL_OPCODE	H_SET_MODE
+
+#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/powerpc/spapr.h b/powerpc/spapr.h
index 0537f88..4c6e349 100644
--- a/powerpc/spapr.h
+++ b/powerpc/spapr.h
@@ -16,10 +16,7 @@
 
 #include <inttypes.h>
 
-/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
-#define __KERNEL__
 #include <asm/hvcall.h>
-#undef __KERNEL__
 
 #include "kvm/kvm.h"
 #include "kvm/kvm-cpu.h"
-- 
2.3.5

[PATCH v2] powerpc: add hvcall.h header from Linux

[Andre Przywara]

The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy just the needed macro definitions from the
kernel's (private) hvcall.h file and remove the extra tricks formerly
used to be able to include this header file directly.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,

this version of the header file just contains the definitions we
need, while still being easily diff-able against the original file.
Please consider applying this one.

Cheers,
Andre.

 powerpc/include/asm/hvcall.h | 33 +++++++++++++++++++++++++++++++++
 powerpc/spapr.h              |  3 ---
 2 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 powerpc/include/asm/hvcall.h

diff --git a/powerpc/include/asm/hvcall.h b/powerpc/include/asm/hvcall.h
new file mode 100644
index 0000000..9d58f9b
--- /dev/null
+++ b/powerpc/include/asm/hvcall.h
@@ -0,0 +1,33 @@
+#ifndef _ASM_POWERPC_HVCALL_H
+#define _ASM_POWERPC_HVCALL_H
+
+/* This file is a trimmed-down version of arch/powerpc/include/asm/hvcall.h. */
+
+#define H_SUCCESS	0
+
+#define H_HARDWARE	-1	/* Hardware error */
+#define H_FUNCTION	-2	/* Function not supported */
+#define H_PRIVILEGE	-3	/* Caller not privileged */
+#define H_PARAMETER	-4	/* Parameter invalid, out-of-range or conflicting */
+
+#define H_SET_DABR		0x28
+#define H_LOGICAL_CI_LOAD	0x3c
+#define H_LOGICAL_CI_STORE	0x40
+#define H_LOGICAL_CACHE_LOAD	0x44
+#define H_LOGICAL_CACHE_STORE	0x48
+#define H_LOGICAL_ICBI		0x4c
+#define H_LOGICAL_DCBF		0x50
+
+#define H_GET_TERM_CHAR		0x54
+#define H_PUT_TERM_CHAR		0x58
+
+#define H_EOI			0x64
+#define H_CPPR			0x68
+#define H_IPI			0x6c
+#define H_IPOLL			0x70
+#define H_XIRR			0x74
+
+#define H_SET_MODE		0x31C
+#define MAX_HCALL_OPCODE	H_SET_MODE
+
+#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/powerpc/spapr.h b/powerpc/spapr.h
index 0537f88..4c6e349 100644
--- a/powerpc/spapr.h
+++ b/powerpc/spapr.h
@@ -16,10 +16,7 @@
 
 #include <inttypes.h>
 
-/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
-#define __KERNEL__
 #include <asm/hvcall.h>
-#undef __KERNEL__
 
 #include "kvm/kvm.h"
 #include "kvm/kvm-cpu.h"
-- 
2.3.5

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

Hi,

On 06/17/2015 10:43 AM, Andre Przywara wrote:
> For converting the guest/init binary into an object file, we call
> the linker binary, setting the endianness to big endian explicitly
> when compiling kvmtool for powerpc.
> This breaks if the compiler is actually targetting little endian
> (which is true for the Debian port, for instance).
> Remove the explicit big endianness switch from the linker call to
> allow linking on little endian PowerPC builds again.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> this fixed the powerpc64le build for me, while still compiling fine
> for big endian. Admittedly this whole init->guest_init.o conversion
> has its issues (with MIPS, for instance), which deserve proper fixing,
> but lets just fix that build for now.
> 

Will was concerned about breaking toolchains where the linker does not
default to 64-bit. Is that an issue we care about?
AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
conversion of guest/init. For this we rely on the resulting .o file to
have the same ELF target as the other object files to be finally linked
into the lkvm binary. As we don't compile guest/init with CFLAGS, there
is a possible mismatch.

I am looking into a proper fix for this now (compiling guest/init with
CFLAGS, calling $CC with linker options instead of $LD and allowing CC
and LD override). Still struggling with MIPS, though :-(

If someone is eager to fix compilation on PowerPC meanwhile, feel free
to use this fix for the time being.

Cheers,
Andre.

> 
>  Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6110b8e..c118e1a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -149,7 +149,6 @@ ifeq ($(ARCH), powerpc)
>  	OBJS	+= powerpc/xics.o
>  	ARCH_INCLUDE := powerpc/include
>  	CFLAGS 	+= -m64
> -	LDFLAGS += -m elf64ppc
>  
>  	ARCH_WANT_LIBFDT := y
>  endif
> 

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

Hi,

On 06/17/2015 10:43 AM, Andre Przywara wrote:
> For converting the guest/init binary into an object file, we call
> the linker binary, setting the endianness to big endian explicitly
> when compiling kvmtool for powerpc.
> This breaks if the compiler is actually targetting little endian
> (which is true for the Debian port, for instance).
> Remove the explicit big endianness switch from the linker call to
> allow linking on little endian PowerPC builds again.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Hi,
> 
> this fixed the powerpc64le build for me, while still compiling fine
> for big endian. Admittedly this whole init->guest_init.o conversion
> has its issues (with MIPS, for instance), which deserve proper fixing,
> but lets just fix that build for now.
> 

Will was concerned about breaking toolchains where the linker does not
default to 64-bit. Is that an issue we care about?
AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
conversion of guest/init. For this we rely on the resulting .o file to
have the same ELF target as the other object files to be finally linked
into the lkvm binary. As we don't compile guest/init with CFLAGS, there
is a possible mismatch.

I am looking into a proper fix for this now (compiling guest/init with
CFLAGS, calling $CC with linker options instead of $LD and allowing CC
and LD override). Still struggling with MIPS, though :-(

If someone is eager to fix compilation on PowerPC meanwhile, feel free
to use this fix for the time being.

Cheers,
Andre.

> 
>  Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6110b8e..c118e1a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -149,7 +149,6 @@ ifeq ($(ARCH), powerpc)
>  	OBJS	+= powerpc/xics.o
>  	ARCH_INCLUDE := powerpc/include
>  	CFLAGS 	+= -m64
> -	LDFLAGS += -m elf64ppc
>  
>  	ARCH_WANT_LIBFDT := y
>  endif
> 

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Michael Ellerman]

On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
> Hi,
> 
> On 06/17/2015 10:43 AM, Andre Przywara wrote:
> > For converting the guest/init binary into an object file, we call
> > the linker binary, setting the endianness to big endian explicitly
> > when compiling kvmtool for powerpc.
> > This breaks if the compiler is actually targetting little endian
> > (which is true for the Debian port, for instance).
> > Remove the explicit big endianness switch from the linker call to
> > allow linking on little endian PowerPC builds again.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > this fixed the powerpc64le build for me, while still compiling fine
> > for big endian. Admittedly this whole init->guest_init.o conversion
> > has its issues (with MIPS, for instance), which deserve proper fixing,
> > but lets just fix that build for now.
> 
> Will was concerned about breaking toolchains where the linker does not
> default to 64-bit. Is that an issue we care about?

Yeah, that would be Debian & Ubuntu BE at least, and maybe Fedora too? I'm not
sure how you compiled it big endian?

> AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
> conversion of guest/init. For this we rely on the resulting .o file to
> have the same ELF target as the other object files to be finally linked
> into the lkvm binary. As we don't compile guest/init with CFLAGS, there
> is a possible mismatch.
> 
> I am looking into a proper fix for this now (compiling guest/init with
> CFLAGS, calling $CC with linker options instead of $LD and allowing CC
> and LD override). Still struggling with MIPS, though :-(

Yeah that's obviously a better solution medium term.

Can you do something like this? Sorry untested:

diff --git a/Makefile b/Makefile
index 6110b8e..8663d67 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,11 @@ ifeq ($(ARCH), powerpc)
        OBJS    += powerpc/xics.o
        ARCH_INCLUDE := powerpc/include
        CFLAGS  += -m64
-       LDFLAGS += -m elf64ppc
+       ifeq ($(call try-build,$(SOURCE_HELLO),$(CFLAGS),-m elf64ppc),y)
+               LDFLAGS += -m elf64ppc
+       else
+               LDFLAGS += -m elf64leppc
+       endif
 
        ARCH_WANT_LIBFDT := y
 endif


cheers

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Michael Ellerman]

On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
> Hi,
> 
> On 06/17/2015 10:43 AM, Andre Przywara wrote:
> > For converting the guest/init binary into an object file, we call
> > the linker binary, setting the endianness to big endian explicitly
> > when compiling kvmtool for powerpc.
> > This breaks if the compiler is actually targetting little endian
> > (which is true for the Debian port, for instance).
> > Remove the explicit big endianness switch from the linker call to
> > allow linking on little endian PowerPC builds again.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Hi,
> > 
> > this fixed the powerpc64le build for me, while still compiling fine
> > for big endian. Admittedly this whole init->guest_init.o conversion
> > has its issues (with MIPS, for instance), which deserve proper fixing,
> > but lets just fix that build for now.
> 
> Will was concerned about breaking toolchains where the linker does not
> default to 64-bit. Is that an issue we care about?

Yeah, that would be Debian & Ubuntu BE at least, and maybe Fedora too? I'm not
sure how you compiled it big endian?

> AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
> conversion of guest/init. For this we rely on the resulting .o file to
> have the same ELF target as the other object files to be finally linked
> into the lkvm binary. As we don't compile guest/init with CFLAGS, there
> is a possible mismatch.
> 
> I am looking into a proper fix for this now (compiling guest/init with
> CFLAGS, calling $CC with linker options instead of $LD and allowing CC
> and LD override). Still struggling with MIPS, though :-(

Yeah that's obviously a better solution medium term.

Can you do something like this? Sorry untested:

diff --git a/Makefile b/Makefile
index 6110b8e..8663d67 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,11 @@ ifeq ($(ARCH), powerpc)
        OBJS    += powerpc/xics.o
        ARCH_INCLUDE := powerpc/include
        CFLAGS  += -m64
-       LDFLAGS += -m elf64ppc
+       ifeq ($(call try-build,$(SOURCE_HELLO),$(CFLAGS),-m elf64ppc),y)
+               LDFLAGS += -m elf64ppc
+       else
+               LDFLAGS += -m elf64leppc
+       endif
 
        ARCH_WANT_LIBFDT := y
 endif


cheers

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

Hi Michael,

On 19/06/15 02:08, Michael Ellerman wrote:
> On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 06/17/2015 10:43 AM, Andre Przywara wrote:
>>> For converting the guest/init binary into an object file, we call
>>> the linker binary, setting the endianness to big endian explicitly
>>> when compiling kvmtool for powerpc.
>>> This breaks if the compiler is actually targetting little endian
>>> (which is true for the Debian port, for instance).
>>> Remove the explicit big endianness switch from the linker call to
>>> allow linking on little endian PowerPC builds again.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> Hi,
>>>
>>> this fixed the powerpc64le build for me, while still compiling fine
>>> for big endian. Admittedly this whole init->guest_init.o conversion
>>> has its issues (with MIPS, for instance), which deserve proper fixing,
>>> but lets just fix that build for now.
>>
>> Will was concerned about breaking toolchains where the linker does not
>> default to 64-bit. Is that an issue we care about?
> 
> Yeah, that would be Debian & Ubuntu BE at least, and maybe Fedora too? I'm not
> sure how you compiled it big endian?

I have my own cross-compiler built from scratch. This is
powerpc64-linux-gnu, which is big endian. I don't have any distribution
behind it, it's just a cross-compiler with glibc.

>> AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
>> conversion of guest/init. For this we rely on the resulting .o file to
>> have the same ELF target as the other object files to be finally linked
>> into the lkvm binary. As we don't compile guest/init with CFLAGS, there
>> is a possible mismatch.
>>
>> I am looking into a proper fix for this now (compiling guest/init with
>> CFLAGS, calling $CC with linker options instead of $LD and allowing CC
>> and LD override). Still struggling with MIPS, though :-(
> 
> Yeah that's obviously a better solution medium term.
> 
> Can you do something like this? Sorry untested:
> 
> diff --git a/Makefile b/Makefile
> index 6110b8e..8663d67 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -149,7 +149,11 @@ ifeq ($(ARCH), powerpc)
>         OBJS    += powerpc/xics.o
>         ARCH_INCLUDE := powerpc/include
>         CFLAGS  += -m64
> -       LDFLAGS += -m elf64ppc
> +       ifeq ($(call try-build,$(SOURCE_HELLO),$(CFLAGS),-m elf64ppc),y)
> +               LDFLAGS += -m elf64ppc
> +       else
> +               LDFLAGS += -m elf64leppc
> +       endif
>  
>         ARCH_WANT_LIBFDT := y
>  endif

Nah, actually I want to get rid of those LDFLAGS at all. For some
reasons using ld to convert a random binary file into a C object is
causing trouble on MIPS, because ld uses a slightly different ELF target
than CC there.
I think this conversion should be more a job for objcopy than for ld,
but that does not fix the problem in a generic way (though I was able to
hack it with some magic objcopy options).

What works though is using xxd to convert the binary guest/init into a C
array:
$ xxd -i guest/init | $(CC) -x c -c - -o guest/guest_init.o
This has the nice property of using the same compiler that generates the
other object files and thus automatically matches them (which is a
problem under MIPS atm, as ld seems to default to some different ELF type).
The only issue is that xxd is part of the vim package, which would annoy
Emacs users. Not sure we are in a position to mandate vim for compiling
kvmtool ;-)

Cheers,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara]

Hi Michael,

On 19/06/15 02:08, Michael Ellerman wrote:
> On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 06/17/2015 10:43 AM, Andre Przywara wrote:
>>> For converting the guest/init binary into an object file, we call
>>> the linker binary, setting the endianness to big endian explicitly
>>> when compiling kvmtool for powerpc.
>>> This breaks if the compiler is actually targetting little endian
>>> (which is true for the Debian port, for instance).
>>> Remove the explicit big endianness switch from the linker call to
>>> allow linking on little endian PowerPC builds again.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> Hi,
>>>
>>> this fixed the powerpc64le build for me, while still compiling fine
>>> for big endian. Admittedly this whole init->guest_init.o conversion
>>> has its issues (with MIPS, for instance), which deserve proper fixing,
>>> but lets just fix that build for now.
>>
>> Will was concerned about breaking toolchains where the linker does not
>> default to 64-bit. Is that an issue we care about?
> 
> Yeah, that would be Debian & Ubuntu BE at least, and maybe Fedora too? I'm not
> sure how you compiled it big endian?

I have my own cross-compiler built from scratch. This is
powerpc64-linux-gnu, which is big endian. I don't have any distribution
behind it, it's just a cross-compiler with glibc.

>> AFAICT LDFLAGS is only used in this dodgy binary-to-object-file
>> conversion of guest/init. For this we rely on the resulting .o file to
>> have the same ELF target as the other object files to be finally linked
>> into the lkvm binary. As we don't compile guest/init with CFLAGS, there
>> is a possible mismatch.
>>
>> I am looking into a proper fix for this now (compiling guest/init with
>> CFLAGS, calling $CC with linker options instead of $LD and allowing CC
>> and LD override). Still struggling with MIPS, though :-(
> 
> Yeah that's obviously a better solution medium term.
> 
> Can you do something like this? Sorry untested:
> 
> diff --git a/Makefile b/Makefile
> index 6110b8e..8663d67 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -149,7 +149,11 @@ ifeq ($(ARCH), powerpc)
>         OBJS    += powerpc/xics.o
>         ARCH_INCLUDE := powerpc/include
>         CFLAGS  += -m64
> -       LDFLAGS += -m elf64ppc
> +       ifeq ($(call try-build,$(SOURCE_HELLO),$(CFLAGS),-m elf64ppc),y)
> +               LDFLAGS += -m elf64ppc
> +       else
> +               LDFLAGS += -m elf64leppc
> +       endif
>  
>         ARCH_WANT_LIBFDT := y
>  endif

Nah, actually I want to get rid of those LDFLAGS at all. For some
reasons using ld to convert a random binary file into a C object is
causing trouble on MIPS, because ld uses a slightly different ELF target
than CC there.
I think this conversion should be more a job for objcopy than for ld,
but that does not fix the problem in a generic way (though I was able to
hack it with some magic objcopy options).

What works though is using xxd to convert the binary guest/init into a C
array:
$ xxd -i guest/init | $(CC) -x c -c - -o guest/guest_init.o
This has the nice property of using the same compiler that generates the
other object files and thus automatically matches them (which is a
problem under MIPS atm, as ld seems to default to some different ELF type).
The only issue is that xxd is part of the vim package, which would annoy
Emacs users. Not sure we are in a position to mandate vim for compiling
kvmtool ;-)

Cheers,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Michael Ellerman]

On Fri, 2015-06-19 at 17:15 +0100, Andre Przywara wrote:
>
> What works though is using xxd to convert the binary guest/init into a C
> array:
> $ xxd -i guest/init | $(CC) -x c -c - -o guest/guest_init.o
> This has the nice property of using the same compiler that generates the
> other object files and thus automatically matches them (which is a
> problem under MIPS atm, as ld seems to default to some different ELF type).
> The only issue is that xxd is part of the vim package, which would annoy
> Emacs users. Not sure we are in a position to mandate vim for compiling
> kvmtool ;-)

You'd be doing them a favor, so fine by me :)

cheers


--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Michael Ellerman]

On Fri, 2015-06-19 at 17:15 +0100, Andre Przywara wrote:
>
> What works though is using xxd to convert the binary guest/init into a C
> array:
> $ xxd -i guest/init | $(CC) -x c -c - -o guest/guest_init.o
> This has the nice property of using the same compiler that generates the
> other object files and thus automatically matches them (which is a
> problem under MIPS atm, as ld seems to default to some different ELF type).
> The only issue is that xxd is part of the vim package, which would annoy
> Emacs users. Not sure we are in a position to mandate vim for compiling
> kvmtool ;-)

You'd be doing them a favor, so fine by me :)

cheers


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in